twin towers

Agile - Scrum

Agile-Scrum is it a new hype or is it worth doing? 

And if you are doing it does it bring what you expect? If you think you are going to do it then how are you planning to start this?

We over the following services to Agile teams:
  • Software - to help you plan and track Agile team
  • Reviews - to help you identify where Agile or software development related issue are
  • Coaching - to help you start your first Agile project and/or (re)energize your Agile team
To show you we have deep understanding about Agile and software development and can truly help in more then one way please see below.

The headline are just some of the questions many software development teams struggle with. As always there is no right or holy grail path towards success. Foremost it needs to FIT your team and your company. Why? Because it is as much about believing it as well as executing it correctly. 

The most difficult part is starting but we have seen many software development groups struggle with Agile not getting the benefits they expect from it. That raises the question why that is. Here is what we believe causing this:
  • It is a big step going from detailed planning to short burst of complexity
  • Complexity is inherent difficult to objectify or quantify (it takes years to get it right)
  • Software development is different than software maintenance or creating a nice interactive website (can be quite complex too)
After years of working with Agile/Scrum in software development teams we came to the conclusion that one need an upgraded version of Agile/Scrum especially if you are in the process of creating new innovative software solutions. The process itself of creating or extending software is already difficult enough. We therefore would like to introduce you a Agile+ version which could help you ease in at the beginning of introducing Agile/Scrum and/or is able to serve you better during the entire Agile process.

To be clear, there is nothing wrong with Agile, we just strongly belief it could be improved or modified to suit demands of (software) companies better. More then 3 years of practical experience went into below thinking and work.

Agile+
We call it Agile+ because in essence it is Agile plus normal time planning. We assume that you are familiar with Agile, Scrum and Sprints, if not follow this link for a good starting place. To help you understand or use it in practice we developed over the years an MS Excel program that aids you in the planning process and tracking during a sprint. This software is offered as shareware for a very low price per scrum master or developers using it (see below) and perhaps it is a good idea to download it as we will explain the process using this software.
So, lets get started with describing the process of planning a sprint, the publishing of the sprint and than later followed by tracking the sprint.
Hint: in the software make sure to fill in all yellow fields, all other fields are derived from these and do not require any input from you.

Planning:

In a few simple
 steps we will explain the Agile+ planning process
Main: 

Decide whether you want to run this sprint of 2,3 or 4 weeks. You can change this for each sprint as you wish.
 
Recommendation: try to stick with sprints of same durations, switching back and forth makes it harder on developers and company to keep track of project.
On the Totals sprint tab fill in the duration of this sprint. You can also name your company/project and what the sprint number is. We opt for numbering these for ease and not name them (you run out of names quickly). Next fill in the day that you will start, make a habit of starting always at the same day in the week. If any (public) holidays fall within your sprint duration put the number of days under holidays. This will make sure they get subtracted correctly. We did mot opt to automated this as different countries have very different (public) holidays or company events.

Developers:

Now go to the developers tab and add the number of developers with two choices, either they work the whole duration the same amount of days or specify per week exactly how many days they work in that week (see also help section next to it)

Recommendation: avoid as much as possible part-time developers, below 4 days a week they tend to slow down your project and lower the output and quality. Exceptions are always possible but after 30 years of experience we can safely say these exceptions are a rare find.
Story list (Repeat for each story):

Go the the first Slist tab for planning your first Story in Agile+ style. The first part is Agile compliant, sorry no easy escape here, you name your sprint to (hopefully) something sensible and you determine the complexity by giving it a number of story points between 1 (simple) to 10 (impossible almost).
Hint: the software will not allow numbers over 11 as we suggest you breakdown the complexity into more doable tasks.
Now comes the Agile+ part, for every task you name you need to estimate the number of hours of work that task will take to your or the Agile team best guess. We make it an habit always to plan together. Lastly, if you are not sure yet this story will make it to the sprint and/or gets on hold for this sprint you can mark it Nice To Have causing the effort being taking out of sprint calculations but still visible to the Agile team that we would like to have it in this sprint.
This mixture of complexity (clean Agile) and estimating duration (normal planning) makes the combination much more predictable, better track-able and easier for Agile developers to work. We made agreements that at mid-point of a task, that is 50% of time spent, the developer checks with him/herself whether they are on track or not. When not than the Agile way would be to ask for help or in the standing up meeting next morning state this and ask for help. As Agile also has a quality loop back with retrospective meeting we also filling in the real used amount of hours in the hours used column. This way we can spot where we under/over estimate or who (or which team) consistently over/under estimates. We also compared the complexity to hours estimated and actual spend to see whether we over/under estimated the complexity.
Hint: we also tracked additional tasks, which in true Agile should not happen or be allowed, to use in retrospective meeting and planning next sprint. The more tasks added and/or hours spend in those extra tasks the more complex that story has become. Similar stories in future would get higher complexity points.
For those Agile purist amongst readers, the complexity of a story and the amount of hours do NOT have a relationship, thus the more complex does not mean automatically more hours. In practice we did see that the more complex the longer durations in single tasks were. But as said earlier if the complexity feels too large, break it down in smaller pieces. This enhances the chance greatly to complete items on time.
30 years of planning and execution experience showed that tasks need to be kept short/small and actually Agile works this way best too. So stories in our software have maximum numbers for tasks because a story with too many tasks becomes a sprint on itself and thus hard to track and/or hard for the team to create successes. One of the true powers of Agile is that an Agile team can score at least 80% of all targets. Stretch targets is nice but failing 100% will not motivate the team not the company or its clients.