Finding Predictability in an Agile World

Reading Time: 6 minutes

Agile, it just might be one of the biggest buzz words in Software Development. It’s right up there with usual suspects like Big Data and Synergy. And it should be. There’s no denying that Agile software development practices have revolutionized the industry. By valuing speed of delivery above all else, “The Agile Manifesto” has attracted a wide community of followers and continues to grow in popularity. And no, I do not mean a manifesto that is both fast and easily changeable, as the title would suggest. Developers have started using Agile as a noun instead of the adjective. This allows for silly sentences like “We need more Agile” to not only be grammatically correct but make sense in certain circles.

Based on the popular proclamation “The Manifesto of Agile Software Development”, Agile Software Development was conceived around 4 key values: Individuals and Interactions over Processes and Tools, Working Software over Comprehensive Documentation, Customer Collaboration over Contract Negotiation, Responding to Change over Following a Plan[1]. To a true believer, this is the only way to be successful. I have read books comparing Agile Vs Predictive methodologies where Agile was given the title of “value driven”[2] while Predictive was written off as overhead and unlikely to succeed. Many of these books are written by industry leaders, some of which I consider mentors for my career. After reading these books and articles, I still have one question that seems to be overlooked by most in the industry: How can agile practices add value if a core value of the customer is predictability? Is there a method that allows for Agile practices to work hand and hand with Predictive practices? In this article, I will explore the background that brings up the question, my Team’s solution to the problem, and some lessons learned along the way.

 

Background

I have a small sized team that works as an internal IT shop. The team consists of myself (team supervisor), 4 developers, and one part-time intern. We are responsible for 3rd party software implementations, 1st party app development, and general support for everything we push to production. Seeing as we don’t have a full time project manager on staff, the developers are responsible for the management of their projects. They pick the style of management that best suites the problem and by no surprise, almost all projects involving app development typically end up following an Agile implementation process. Some developers might have the kickoff and the first line of code written in the same day.

Why is this a problem? Well at its core, we are adding value to the business at a speedy rate. By diving right into the code, we are able to get a first release within 1 or 2 weeks (Continuous Delivery Coming Soon!). However, the speed is countered by the unchangeable truth that software is never complete, only abandoned. Even though we have speed of delivery on our side, when is the project complete? This is the question that our customer base is interested in.

Two years ago, we had 3 large concurrent apps being developed by my team. Each release brought these apps to a stronger state of usability, but they just seemed to continue for months. With each release, the users wanted something else. Whether it be an enhancement to the application or a requirement that was originally overlooked, the priorities kept shifting. As a result, the discussions quickly changed from what we are delivering, to what we are not working on as a result of not “closing” the project. Despite shipping customer requests at a fast rate, we were getting a reputation of being slow and stagnant. Our customers all but demanded a change in the way we did work for them. Considering that we have seen pure Predictive methodologies fail just as often, the solution called for a different approach.

 

Solution

The solution we are using, I’m calling Predictably Adaptive, and the key value is this: Enable others to make value decisions within an expected limit. I recently read Creativity Inc. where Ed Catmull discussed this very subject. He described a room with popsicle sticks on the wall. Each stick represented a “programmer week” of work (hold your jokes please). They went through assigning popsicle sticks to each item of work, resulting in a time line for completion. Ed referred to this as a creative limit. The way this worked is, if someone recommended a new feature that would take a programmer week to implement, instead of being strict on the schedule or lax with the man power, they would simply ask “What stick would you like to use for this feature?”. This suggesting that if we want this feature, another feature may need to be delayed[3].

Our implementation is not much different from this. We start the project off with heavy planning instead of instant code. A schedule with target dates is composed and we begin to iterate changes to the customer in a quick fashion. With every release, we encourage a feedback loop that allow the customer to recommend additions/changes. At each loop the developer provides an estimation and enables the customer to make decisions based off the current target dates, project progression, and new estimates from the developer.

Flowchart

With this information there are 3 typical decision points at each feedback loop:

  • Replace a time equivalent feature on the project list with the newly suggested feature (stay on timeline)
  • Add newly requested feature to future enhancement wish list (stay on timeline)
  • Add newly requested feature to the list and extend the target dates accordingly (alter timeline)

All options are acceptable decisions and can only be made if the project manager or developer educates the customer of the impacts. Where previously these decisions were being made in the dark and most of the time by the developer, we have found by empowering the customer to make informed decisions they have more ties to the final outcome and allows for the developers to only deliver on highest priority items. Since implementation, we have seen an increased turn around on highest priority projects and we are steadily regaining our reputation of being a “quick to deliver” team.

 

Lessons learned

Programmers by nature are more interested in coding than planning. This isn’t exactly a profound statement I know, but this is something that caused some conflict from within the team during the change. To developers that are used to Agile methods, planning seems like wasted time. It seemed like any suggestion other than Agility was viewed as equivalent to a Waterfall style of project implementation (zero feedback loops). So it did take some effort to get everyone comfortable with the proposed change. I was able to accomplish this in a couple of ways.

  • Communicate the why – I took a lot of time to educate the team on why we are making the change. To them, when I advocated for more thorough planning, they all thought I was ready to take the team down the road that gave rise to Agile methods in the first place. To gain the team’s trust and build their confidence in the plan, I was completely transparent with the problem we were trying to solve. By sharing the values and perception of our customers, the team became more inclined to change things up making the transition much easier. Their openness was necessary for a smooth experiment.
  • Be intentional with the vocabulary – Make sure that both the developers and business partners know that we are not setting deadlines, but instead we are declaring target dates. This is an important distinction. Deadlines can be extremely dangerous due to an assumption that a deadline cannot move. When dates don’t move, that causes developers to cut corners and sacrifice quality to meet the objective. This typically is a lose-lose situation. Targets on the other hand are understood to move. If you keep your eye on the target as you get closer, you will be better equipped to handle the “unknown unknowns” when they arrive. All you have to do is understand where the new target is and continue to move forward. Education of this difference is absolutely key.
  • Encourage the customer to have a stake – When it’s time for a feedback loop, make sure the business partner knows what to expect. Educate them on the process and encourage them to not only provide free feedback but also to participate in the decision making process that may follow. This allows the business partner to understand what the scope of the request is and possibly come up with a creative solution to get to the ideal outcome. This strengthens the relationship and can improve the overall quality of the project

Overall, I am excited with what the team has been able to accomplish over the last year and a half with this implementation. The product output has been great and our customer relationships get better with every release. I cannot guarantee that the solution has scalability. However, for a medium sized, lean, internal development team, having the power to make decisions based on predictability has been a powerful tool and something we have been building success around. If others have solutions for the same problem, I would love to hear ideas or feedback from your experiences so please leave me a comment below.

 

[1] http://agilemanifesto.org/

[2] Agile IT Organization Design by Sriram Narayan

[3] Creativity, Inc. Overcoming the Unseen Forces that Stand in the way of True Inspiration by Ed Catmull

Share This: