Agile By the Numbers – Which Ones Don’t Make Sense?

As an agile practitioner I have had the chance to participate in many different projects over the last five years. I have had a chance to see projects of beauty and those that simply did not go as desired. Recently, I was asked to support a project where the customers’ IT team was embracing agile and trying to follow a SCRUM based approach ‘by the numbers’. It was this project that shone some light on the way we practice Agile here at OutSystems and has helped me really reflect on our enterprise approach and things we practice that just make sense.

paint-by-numbers.png

Now, don’t misunderstand. The customer had good reason for the ‘by the numbers’ approach, but I found many steps/processes impractical, slow, and in some instances frustrating. Here are the ‘by the numbers’ items that I found painful and why.

 

Project Analysis: The team did no up front analysis, and only did analysis as they entered each sprint. By not doing some high level analysis for the entire project at the beginning, we could not anticipate the best architecture. This lead to a lot more refactoring than I’m used to on a project. It also hinders the ability to do any early usability analysis, something we at OutSystems have found to be vital for delivering a great app!

 

Story Pointing: The ‘by the numbers’ approach made us do story pointing (assigning points to stories as an abstract measure of its complexity) and sprint planning (estimate each story and its tasks to see what fits in the sprint). Turns out that, in my opinion, story point analysis is amazingly painful, inefficient, and not very accurate – especially if you are setting up a new team, working on a relatively small project, or have little prior experience on the type of project you’re embarking. Not only that, it becomes redundant compared with sprint planning, which definitely cannot be skipped. The sizing approach we have devised is much more accurate and efficient, plus it directly supports our sprint planning efforts saving us time. However, it does require some high level analysis around user stories and data.

 

Team Interaction: While I am a firm believer in scrums – we use them daily – there is a point where you don’t need the whole team to participate in each and every decision that is taken on the project. By having everyone on the team participate in every decision, we ended up slowing down the delivery and having folks involved in stuff they had no interest in at all. Some pragmatism in who gets involved in each decision makes a lot of sense. The OutSystems approach really streamlines our decision-making process, by splitting the SCRUM Master responsibilities into two roles: the Engagement Manager and Delivery Manager. This truly helps the project go at light-speed without sacrificing quality.

 

Sprint Demos: Since analysis was done during the sprint, we end up with great business participation. However, at the end of the sprint the final results are anti-climatic as the business team members have been involved every step of the way. The down side is that the business users were way more involved than necessary, something that does not happen in the OutSystems approach. Don’t get me wrong; business user feedback is obviously critical, but just not needed on every hour of every day. Our approach focuses on delivering ‘high impact’ sprint demos where the end customer is amazed at what we deliver. This is where we collect feedback that leads to a more engaged business team and a better overall application.

 

There are lots of ways to practice agile, but a healthy dose of pragmatism, formalism, and common sense will go a long way to help your team move fast and deliver great applications!
About the author

Gonçalo Borrêga

After ten years of hardcore development, Gonçalo got bored with the repetitive tasks that are required project after project. So, he adventured into finding the best way to bring automation and productivity to the rest of us.

Comments

Joost

About the story-points.
What’s exactly the difference between story-points and sizing.
where sizing on the agile-method needs a even bigger understanding about user-stories and what impact it has.
while with SP’s you can give a rough estimate upfront, except for those you are throwing into the sprint.
I find the biggest issue with your sizing you have to know everything upfront and size it accordingly (in contrast of what the agile-manifesto means)
SCRUM and storypoints give you better agility and only focuses on the 1-2 sprints.
the highlevel blueprint of the application you need in both cases, so that is a bit of a false point :)

Gonçalo Borrêga

The story points are really helpful when you have a team experienced in the project they’re working on, the team is fixed or doesn’t change a lot, and you can bare a 50% error (some SPs will be overestimated compensating the under estimated ones).
For the initial estimation, it kind of works ok if you have some previous experience. Over here at OutSystems, we’ve measured a large set of past projects to identify patterns, which allow us to have a better estimation in terms of days. That is usually what you need to give a customer (the # of days the project will take) as he needs real predictability.
On the other hand, in the delivery process of a long-running product, story points are working perfectly for us. We know and constantly measure our velocity, and the story points multiplied by our velocity give us an impressive degree of predictability (higher than I would ever imagine).
The issue with customer projects is that usually they’re not an ongoing effort. You have a fast start, a new team popping in, a new set of business stakeholders dragged into that don’t fully grasp the process (and the challenges of tradeoffs) so you need to adapt.
On the sprint planning, story points are just too broad imo. At that point, you have quite good information of what you need to do to accomplish that sprint goals. The initial estimate gives you the slack to work with changes, but before the sprint starts I like to really detail and plan that sprint, already considering the feedback from the previous demo. It becomes easir to have the buy in from the development team, because they study in detail what they need to do.
So… I agree that pure SCRUM and storypoints give you more agility… but how far can you go (or how relaxed can you be) with SCRUM for a 3 or 4 months project, on a team for which you don’t know the velocity yet?

Leave Your Comment

contact pricing contact try