Software | Technology

[my-twisted-code]

[swagile]

Don’t Complain About Business Requirements.  Take Responsibility and Collaborate.

I have 16 years experience in telecoms and IT.  Started out as a software design engineer then team leader, project manager, product manager, agile coach, business analyst.

“The business requirements were not clear enough.”   “We didn't have enough detail in the business requirements.”  “There is too much detail in the business requirements.”

If you hear something like that then you are most likely listening to a team that is making excuses for failing to deliver or reluctant to begin the design phase.

This problem is almost always a symptom of the inappropriate adoption of the waterfall software development process.  Let me explain why I use the word ‘inappropriate’.  I’ve been fortunate in my career to work on cutting edge projects i.e. building software systems or products that have either never been done before in the industry or have never been done before by the team I’ve been working in.  I believe that the waterfall approach is not suitable for these types of projects.  In my opinion, the waterfall model suits projects that are ‘turning the handle’, so to speak, implementing/deploying a system or product that has been done before and we can confidently predict the steps required to bring the system/product to life.

For the cutting edge projects, a more collaborative, iterative approach is more suitable.  Starting with a rough idea and then spiralling in onto the solution, learning from the mistakes after each iteration.  John Maynard Keynes got it spot on when he said:-

“It is better to be roughly right than precisely wrong.” - John Maynard Keynes

Quite frankly, this is the most exciting and rewarding way to work and a positive attitude and good team spirit is essential.

My heart sinks when design teams adopt a defensive position and hold a negative attitude when presented with a set of business requirements.  However, in waterfall projects I can hardly blame them because after all the documents are signed off and you are “holding the ball” and things don’t go according to plan then you get the blame.

So what do I hope for when having to work on a waterfall project? Well, I would hope that the design team gets involved and speaks up in a positive and collaborative manner during the requirements phase and if something is not clear or does not make sense then get involved and collaborate until you are comfortable to proceed.  You will be waiting a very long time if you want perfect requirements - spending too long in the requirements phase for a cutting edge project is counter productive, get it roughly right and start building.

Equally, the business representatives must be comfortable with the cost of changing direction if things are not working out.  The business can’t just throw ideas at the technical delivery teams expecting them to arrive at the perfect solution.  Both sides need to compromise.

This is my opinion. If you have a different point of view then please comment.

[swagile]

Sprint Zero

There is much talk about sprints and the day-to-day running of a project.  Not enough talk, in my opinion, about the start-up phase of an Agile project. I like to use the Sprint 0 concept.  Its during this sprint, which can be any length depending on the scope of the project, where we capture enough information to put us in a position to be confident about starting proper, i.e. a deep enough, estimated,  backlog to start Sprint 1. We collect user stories, we think horizontally (architectural ideas), identify risks, do some UX concepting.  We might augment key user stories with more detail e.g. append use case documents to them if we think it's appropriate. The pressure to provide a realistic cost estimate plays a key role in determining how far we take Sprint 0.  It's a balance between doing enough to give you the confidence to make an estimate, against falling into the trap of analysis paralysis. Sprint 0 is not always required.  For example, if we have implemented something similar in the past then we are already in a position to start Sprint 1 i.e. deliver value to the customer, because we are already confident about our approach and development environment. Sprint 0 is about getting the team ready to start.  By team I mean everyone, even the Finance Director! By the end of Sprint 0 you should have:- • The Project/Product Vision • Some UX Concepts • The Backlog • The Architecture Overview • A Budget Estimate • Target Velocity and Burndown Chart ready • The Definition of Done • Stakeholder List • A Team or Teams Organised

[swagile]

Managing risk on an Agile project. My favourite way to do this is by way of using the burndown chart. In just the same way that we monitor development using the burndown chart we can also use it for monitoring risk. Here’s how.

Most teams rate their risks according to impact and likelihood of occurrence. You must continue to do this. For example I do the following:-

1.) Rate the risk in terms of impact should it occur (impact): 1 = Negligible, 2 = Minor, 3 = Moderate, 4 = Serious, 5 = Disastrous.

2.) Rate the risk in terms of likelihood of occurrence (probability): 1 = Very unlikely, 2 = Fairly likely, 3 = 50/50 chance, 4 = Fairly likely, 5 = Almost certain.

3.) Now calculate the risk exposure for each risk: risk exposure = impact x probability.

4.) Sum the risk exposures for all your risks.

5.) Plot this on a line graph (Y axis = Exposure, X axis = Time).

Ok now we are ready to start managing our risks during the project. As the team starts implementing, the “fog of war” begins to get pushed back as we learn more and more. At the end of each sprint the team reviews the risks and changes their ratings if needed.

If the risk exposure is not burning down then this is your cue to do something about it. E.g. dedicate the next two sprints to mitigating risk. You can take your burndown chart and risk log with you when meeting the stakeholders - this helps them understand the need to dedicate time to it.

[agabrillagues]

“A high level view of the role of the Scrum Master”

I’ve found this great sketch on the “Illustrated Agile” blog.

[swagile]

To Size Or Not To Size

In my early days of experiencing SCRUM we used to be in a dilemma about whether or not to size bugs.  It was an old piece of software with a lot of history and therefore a lot of technical debt.

The backlog contained a mixture of new user stories and bugs.  In the beginning we were assessing the bugs and assigning story points to them.  This felt really "agile" and so we continued like that for some time.

However, the unpredictable nature of bug fixing really became a problem.  During the sprint a new high priority bug would come in and we did not know quite how to handle it.  Cancel the sprint? Break the principle of respecting the teams commitment for that sprint?  How "big" is the bug? etc.

A year later and the team is very adept at working according to Agile principles and this is how we handle bugs:-

Remember that a team's velocity represents it's capacity to implement change (new features).  Bugs are NOT sized.  The team works in a mixture of SCRUM and Kanban depending on the business priority.  If the business needs 100% focus on bug fixing then the team falls into a Kanban mode - picking bugs off the queue as they come in (we still maintain a 2 week sprint heartbeat).  If the focus switches to new requirements then it's in SCRUM mode - user story sizing and velocity based planning.  Most of the time its a blend of new features and bug fixing and the team's velocity, over time, naturally reflects that.

At the end of the day, at least you have a velocity that reflects what the team is capable of in terms of implementing new features.  Which is what the management need for road-mapping and planning.

[swagile]

Velocity

Someone said to me “surely you would expect the team’s velocity to continue to rise”.

I have heard this many times and it really misses the point of velocity.  It’s not to say that a well performing team’s velocity will not rise but, as a product owner, you should be looking for a predictable velocity first and foremost.

Remember that the team’s velocity represents the rate at which it can complete new work (implement change) and does not take into account technical debt.  That is to say that it is unfair to link a team’s performance with velocity.  For example they may have inherited some technical debt that they are working on which has now taken up a lot of their capacity (velocity).

So, the goal must always be to achieve a predictable velocity.

In response to this I often get product owners saying that they fear that teams will deliberately underachieve to ensure a predictable velocity.  Sadly, that is a team morale/attitude problem.

So remember, the goal is to achieve a predictable velocity not necessarily an ever increasing one.