Category Archives: Agile

Agile Hurts

It was about 5 years ago that I first got slapped by agile. In that time, I’ve been in several purported agile environments, from pure high velocity environments to full blown faux-gile environments.

It takes me time to really internalize things such as agile. At this point in time I feel like I get it (don’t we always feel that way?). And here is my big lesson: agile is painful, and it’s supposed to be. A quick followup to that: agile isn’t a solution, it’s a mindset that will lead you to a solution.

This may be stating the obvious, but the processes falling under agile such as scrum and kanban drive out the pain points into the open. Extending that idea, you can’t homogenize a process across the board because each team’s problems are different. Perhaps more importantly, to successfully introduce agile into an organization requires everyone having the courage to face the problems that surface.

The biggest failure I see is ignoring these problems and not allowing the team to fix them. If you can’t trust and empower your team members, maybe you hired the wrong people.


Embracing Agile on a Fixed Price Project

Agile and Fixed Price

I’ll be honest, I was nervous. I’ve been developing in agile environments for several years now, and the thought of a fixed price project was frightening. It doesn’t seem like the principles of agile are conducive to a fixed price project. Customer collaboration? Continuous feedback? Responding to change? These concepts sound like they were designed to scuttle a fixed price project. But this is what the client wanted, and I was asked to lead the effort. Sure we had a change control process in place, but that was just going to break momentum in the long run.

Not only was it fixed price, but it was a new team, tackling a new-to-us codebase, and a new technology with a steep learning curve (WPF in this case). Did I mention that nobody on the team was involved in the time estimate? What we had was a list of stories to complete, and an incentive for finishing early. Likewise, there was a dis-incentive for finishing late.

The End Result

I take a lot of pride in the work I do, and I love delivering a product the customer loves just as much as I love a beautiful code solution. Delivering on time seemed impossible, much less delivering a product the customer loved.

It turns out we delivered a four month project three weeks early, and delivered a great solution that the customer loves. I was as surprised as everyone and have been reflecting on how we achieved it.

The Keys to Success

When it comes to agile, there are many principles to live by. The following items are what I tried to focus on.

  • The simplest thing that could possibly work. Our UX guy probably lost several years off his life after all the great ideas that had to be left behind. Build the simplest thing, minimum viable product, maximize the work not done, whatever you want to call it.
  • Continuous feedback from the customer is great. But you’ve got to realize you cannot deliver everything they want, or even everything you want. When you are under a fixed price, you must deliver what is spelled out. There is nothing wrong with telling the customer what is possible, and in fact we would do this all the time. But know that without change control you just can’t do it.
  • Be ruthless. Hopefully your contract has spelled out stories and not detailed specs. With stories, you have more latitude to deliver the simplest thing possible, and ever better, deliver the right solution to the problem. But you must be ruthless. Anything out of scope is out of scope. It’s best if you do this as nicely as possible.
  • We never had any change requests. To be honest I’m not sure if that is good or bad. Maybe we over-delivered. I think if we HAD gotten change requests, I would have liked to tackle them after the initial delivery. I think the momentum loss from the change request would outweigh tackling a change while things are fresh. That may seem a little backwards, but I feel that in a fixed price project you must stay focused on delivering.

Final Thoughts

I won’t lie. The key points above may have had nothing to do with our success. It may have had everything to do with having a great small team (3 devs and 1 UX) focused on a common goal. But if there is a take away, it’s that it is possible, and agile and fixed priced are not necessarily at odds.

Crunch time and Theory of Constraints

I’m continually amazed at the wastefulness and lack of focus I often see in software development. Worst of all, the problems seem to intensify as one gets closer to the deadline. It doesn’t have to be this way if you are focused on continual improvement.

A colleague of mine that I have tremendous respect for turned me on to Eli Goldratt and The Goal: A Process of Ongoing Improvement. While The Goal focuses on manufacturing, it is applicable to other industries as well (see Critical Chain). The basic idea is to identify bottlenecks (or constraints) to throughput, and systematically make improvements to reach the goal of maximizing throughput for the system as a whole. Of course, the theory of constraints was the inspiration for the name of this blog.

Crunch Time

Anyone who has spent time in software development has experienced crunch time. You’re up against a tight deadline, and there is more work than time. The closer you get to the deadline, the more chaotic things get. You have X number of features that must go out, and they are all top priority.  If a feature has to be done, it is of COURSE top priority.  Along with all the other required functionality.  How can we maximize chances at success?

Step One: Identify the constraint

This can be tricky, but very often it is development that is constraining the system. Coding is a time consuming process. For this post, we are going to assume it is the development that is the bottleneck.

Step Two: Exploit the constraint

No, this doesn’t mean treating your developers unfairly. It means utilizing your resource to the fullest. Remove any functionality not absolutely necessary. Re-evaluate targeted functionality for the simplest solution that could possibly work. Prioritize work, even if priorities are arbitrary. When the human brain encounters 10 different #1 priority tasks, nothing is going to get done. By prioritizing, you let development focus on individual tasks.

Step Three: Subordinate every other decision to the constraint

Have you ever been in crunch time and found yourself doing something that is unrelated to your goal and is wasting your time? As an example, if I’m a developer under the gun to get functionality developed, preparing release notes and responding to bug reports via some cumbersome bug tracking system is wasting my time. Find another resource that can handle these things for me so that I (the bottleneck) can focus on my goal. Don’t hand incomplete requirements to your developers that will require them to stop working to clarify.

Step Four: Elevate the constraint

Elevating the constraint is tough during crunch time. In this case, elevation could involve adding people or faster machines for the developers. Neither of these is a good idea when up against a deadline. But outside of that scenario, the above should be considered. Particularly computers. It absolutely baffles me the salaries organizations will pay developers and leave them with 2 or 3 year old machines. Spending $3k on a faster computer is a no-brainer.

Step Five: Repeat

Chances are that if you repeat the above steps, at some point in time your constraint is going to shift. Most likely, it will shift to your testing crew. Repeat the focusing steps to continually improve what you do.

Cross Functional Teams and Systems Thinking

Cross functional teams have been promoted by agile methods for years now, and it can be hard to fully appreciate their value without having experienced the tremendous value of such a team. The same could be said for much of agile practices, but I want to focus on cross functional teams.

What are cross functional teams?

A software development team that is cross functional might include developers, user experience designers, testers, production support, and subject matter experts. All of these individuals work together on a team towards a common goal. This differs from traditional methods where each specialty is in a silo, interacting with other specialties at specified gates or milestones.

Ok, so where is the value?

Having experienced a very successful, cross functional team led me to several conclusions. First, it improves communication among the people working towards the solution. When a developer has an unclear requirement or an alternative idea, it’s natural to turn to a team member who can clarify the requirement or refine the idea. If a tester encounters what might be a bug, it’s a simple matter of turning to the developer to work through the issue. This eliminates all the red tape (in the form of bug tracking) and waste and takes care of the problem quickly. And this arrangement allows for constant collaboration in solving problems, which not only solves problems more quickly, but typically results in a superior solution.

Recently I’ve been involved with a team that is not cross functional. Specifically, developers and testers are firmly segregated. In this organization, a build is handed off at the end of a sprint.  Testing will only be conducted on functionality that is mostly complete. The intent is to minimize retesting, but this goal is misplaced in my opinion. Retesting shouldn’t be the worry, the testing inventory that builds up should.

In thinking about the problem, I realized a significant benefit cross functional teams, and it is that the approach forces systems thinking. Systems thinking, in its simplest form, is consideration of an entire system and how the components interact and affect one another.  It’s simple, when divided into different groups, to focus on local optimization. That is, when I’m a tester thinking only about testing software, my apparent goal is to test software and report bugs. As a developer, my goal is to crank out the spec’d software.

It’s too easy to lose sight that our goal is to deliver solutions, or in agile terms, working software. Actually, that isn’t even quite correct. Our goal is to deliver business value. When we have a cross functional team, we are forced to think in terms of systems, whether we realize it or not. For someone altering requirements, the effects of those decisions are apparent when you are part of the team. When a developer is cranking out too much functionality (oh yes I said it), the effect on the tester sitting next to them will be evident.

We like to talk about constant feedback, and a cross functional team will give you feedback on how the team itself is performing, and how the system is working (or not).

Why the resistance?

Perhaps one of the greatest impediments is territoriality. Managers get queasy about relinquishing their minions to a team. This can even be extrapolated to the fear of empowering teams with decision making, but that is another post.

Mentioned earlier, local optimization is another roadblock. The idea of an employee’s not being 100% utilized in doing their job is heresy. Excess inventory- for example, testing inventory–can cost far more than time spent idle.