Why Should Agile Stop at Software Development?

Wednesday, July 30, 2014 by Rainer Stropek

Agile principles have become quite popular in software development. The approach has proven to be successful many times. Frameworks for agile development like Scrum are not at all limited to software development. Still, the agile approach can rarely be found outside of this domain.

We think, that’s a pity. Many teams know that their internal processes need improvements, yet they do not find the time to specify the big reorganization they have in mind. They are stuck in rigidity wasting time and money day by day. What could make them stop hesitating and start innovating?

“We can’t start as the overall concept isn’t ready yet …”

Could I please have a penny every time I hear this sentence? We were told this even by IT companies that have embraced agile principles in software development. One (potential) customer comes to my mind who I have been in contact with for years. We wrote a concept, employees of the customer wrote another concept. However, they still struggle with old and inefficient time tracking and resource planning software. Even most basic tasks like invoicing are a pain every single month.

In this case, management does not approve the budget for a new software. They say that a new software does only make sense in conjunction with a large-scale reorganization of all internal processes. Nobody exactly knows how the final organization should look like and of course nobody has the time to work out the details. Therefore suffering continues.

Big Design Upfront Often Does Not. Enter Agile.

Does that sound familiar to you? Don’t forget that big design upfront is a concept that simply does not work in many situations. Agile shines in these cases. Here is how you can succeed:

1. You Need to Have a Vision

Agile does not mean to start without any planning. You need to define a vision, a description of how the world will be after your project is completed. In contrast to the big design up front approach, the vision should not be super-detailed, it should be desirable. Here is a fictitious example for a reorg-project in our domain to illustrate what I mean:

Last year, 5% of all invoices we sent to customers were wrong. We had to correct them. On average, it took us until the 15th working day of each month until we had sent out all invoices. In a survey, 75% of our employees said that our time sheet process wastes “many hours of their working time every week”.

We are going to redesign our billing process. Our vision is that our customers value our bills for being correct, easy to understand, and informative. Invoices are a way of staying in touch with customers and we think that this communication channel can be turned into a powerful marketing instrument. Additionally, we will continuously improve our internal processes until we substantially shortened the monthly throughput time for billing.

2. Structure Your Project

Derive a backlog of work based on your vision. Start with high-level user stories, so called “epics”. Sort them by business value. Use the vision and the epics to convince management to approve a small budget to start with.

Here are some examples of epics that might fit to the vision shown above:

  1. Redesign invoice layout and structure
  2. Define and implement an approval workflow for outgoing invoices
  3. Create interfaces for automatic data exchange between time tracking and invoicing system
  4. Evaluate and roll out a new software product for time tracking

At that point you will likely be asked for the overall project budget or time schedule. Don’t hesitate to stay vague on these points.

However, what you can promise is that the project team will show substantial progress within a short time frame (e.g. one month). This is why focusing on the epics with highest business value is so important.

3. Build an Agile Team and Agree on an Agile Project Framework

Form a cross-functional team. The team should combine all the expertise necessary to complete the project. Getting external help for small tasks that require specific knowledge is ok. However, in general your team should be able to work independently. Here is an example for a team structure for our fictitious project:

  1. You (in Scrum you could have the role of the Product Owner or Scrum Master)
  2. A person from your backoffice team with in-depth knowledge of today’s billing process
  3. A project manager
  4. A member of your company’s consulting team
  5. Someone from your internal IT department

If you and your team do not have experience concerning agile methods, get familiar with approaches like Scrum.

Don’t make the mistake and think that working agile means chaos. Agile frameworks like Scrum define rigid processes.

In our experience, reorg projects are often part-time projects. The team members will still have to do their daily job. Therefore it is likely that you have to adapt iteration times (e.g. sprint lengths in Scrum), frequency of meetings (e.g. sprint meetings in Scrum) to your specific needs.

However, make sure that your agile process contains all basic elements of the selected project framework (e.g. Scrum). They have carefully been designed and you will not benefit from them as much as you can if you ignore important aspects.

4. Start Iterating and Innovating

The details of how you work in the project strongly depends on the agile framework that you select. If you are a beginner, I recommend Scrum. It is clearly defined and you will find lots of good information about it in books and on the web.

The most important aspect is the concept of iterations. Working the agile way means continuous improvement with regular retrospection. In our example, the fictitious project team could trigger a positive feedback loop like this:

  1. Within two weeks after starting the project, the invoices got a new appealing design, cleaner structure, and friendlier wording. Customers reacted very positive on this simple change.
  2. Within one month, the team managed to setup a simple but effective workflow in Microsoft SharePoint for project managers to approve invoices before they are sent out to customers. This reduced the number of incorrect invoices remarkably.
  3. After six weeks, the team had completed a company-wide survey for improvement ideas concerning time tracking and billing. The results were partly surprising and immediately influenced the next steps of the project.
  4. After two months the team had worked out a criteria catalog for selecting a new time tracking system which would notably reduce the amount of administrative work for consultants.

Show continuous progress and focus on the most important points. Sometimes small, low-tech changes have massive impact.

We Built Time Cockpit for Continuous Improvement

The possibility to start small and improve step by step has been an important design goal when we created time cockpit.

The software comes with support for typical time tracking scenarios and is ready to use. However, time cockpit is also customizable and extensible. Over time, our customers can tailor it to their specific needs.

They can switch from manual, duplicated data entry to automated interfaces (e.g. to their CRM or accounting solutions). They can extend time cockpit’s data model to cover more aspects of their administrative processes. In more complex and advanced scenarios, they can even start to use time cockpit’s API to add custom functionality differentiate their processes from those of their competitors.

Interested in trying time cockpit or attending one of our Scrum trainings? Please contact us at office@timecockpit.com.

comments powered by Disqus