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 shined some light on the way we practice agile here at OutSystems and has helped me reflect on our enterprise approach and agile practices that just make sense.
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!