Agile, You’re Doing it Wrong

There’s an interesting problem that can appear in companies that develop their own agile IT capabilities. Ceremonies get added, scrum masters are appointed, deliveries ramp up, and all is looking good.

Then a team is formed to tackle some novel problem or implement some new industry buzz word.

I think that having an SDLC will help us.  Let’s get some people on that.

Big data changes all of this.

We need cloud in order to stay relevant.

We need more ALM in order to get ahead.

The team goes to conferences, hires consultants, buys books, reads blogs, brings in vendors, and sequesters itself in a room for weeks to design a perfect solution based on all this information. The result is usually a multi-year timeline with no real detail on what problem is getting solved. Worse, it seems to require everything to be in place for anything to work.

The team may have sprints, and scrum ceremonies and is thought of as being agile because of these characteristics. However, the team is missing the point of agile (and lean for that matter). Teams fall into these traps with good intentions, but they are traps.

Proving the Need

One of the reasons teams often create these models and roadmaps is to prove how much work there is for them to do. Armed with that information, they feel that leaders will come to their senses as soon as they see the weight of it and triple the size of the team. That never happens. Any other team competing for internal investments can create an equally long roadmap. It’s useless. It delivers no value.

Showing leaders a multi-year timeline and saying that the reason you’re not getting things done is because there is too much to do is not a winning strategy.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

A much better way to invest your time is figuring out how you serve your clients this week or this sprint. Look at the capacity you have and use it as best you can. Change the nature of the problem or how you attack it if you need to. What problems are going to be solved? How do these add up with other work being done to turn into big wins?

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Once you’ve established your ability to deliver client value, you’re in a much better position to have a talk with leaders about more team members. But, now you can point to how much you have done, how you’re doing it, and talk about how much more you could do in the coming weeks if you had more team members. You’ve proven you can keep yourselves on track, that you can deliver value, and that you are motivated to deliver what the clients find valuable (not what you or a consultant finds valuable). Leaders are much more likely to invest into that kind of team than to invest into any sort of multi-year roadmap whose team is not yet delivering.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Increasing Knowledge

Sometimes teams focus on creating a utopian version of thie tech or process. They create models, diagrams, and describe what it should look like (to them and the consultants and bloggers and books), often with little regard to the actual process being changed, the people in that process, the problems those people have, the skills of those people, or existing solutions (many of which may not be technical). Once they have this utipian vision, the team becomes confident in how much they now know. Looking at this, the team may imagine that if they just had more people they could do it all so quickly.

Unfortunately, they don’t understand any of it. Worse, the people that will use the solution know and understand even less.

The only way to actually gain organizational understanding, is by doing. No amount of blogs can increase understanding (sorry). Vendors will gladly lineup to sell you tools, but those tools may be looking for a problem in your company rather than solving one.

No conference can confer understanding. Nor can consultants. These are all great venues to gain some quick knowledge and direction, but the only way you can truly understand what it means for your organization is to apply it. Your culture is different. Your current process is different. Your technology is different. The skills of your people are different. The only way you learn these things is by working in that world and gaining understanding for how to solve real problems in your context.

This type of understanding comes slowly. If you want a real solution, though, you must have the disciple to take the time to understand the situation as it is. You must be willing to go slow to go fast.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

You cannot gain understanding in in an off-site with just the team, and not by creating a utopian vision. Take what you have learned externally, sit down with your internal clients, and figure out what you will do together in the next week or sprint to apply it.

7. Working software is the primary measure of progress.

Once you’ve done that, you’ll understand far more in a week than you would have in a year of modeling a perfect process. Continue this sprint after sprint and before long, your team and clients will understand exponentially more of the opportunities and solutions.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Even better, since you’re working to solve actual problems you won’t waste time creating solutions to problems that don’t exist. That is something you can not find in a war room, at a conference, or in talking to a consultant or a vendor. The only way to figure out what you don’t need, is to start doing and learn what’s there that works.

10. Simplicity–the art of maximizing the amount of work not done–is essential.

Lean – Kaizen & PDCA

In a lean improvement, we may get huge changes, but not all at once. It’s the countless kaizen events that each make a small tweak that will accumulate into that big change. Each of these changes are made of many smaller PDCA (plan, do, check, adjust) cycles. These cycles apply some external knowing to an existing problem, but with some testable assertion.

I think that using big data could get us that answer.

I think that a more formal SDLC will help us identify where we are short cutting out processes.

If these experiments are in (or near) the real environment and include the people actually doing the work, you’ll have a better check and know what to adjust for the next cycle.

Lean – Genchi Genbutsu

If you’re working with the people doing the work, where they do it, then you’re getting into the lean principle of genchi genbutsu, which essentially means going and seeing the actual situation.

This would be instead of a summary, second hand knowledge, or just guessing. In our case above, involving the people doing the current jobs that will be impacted by the new process is at least a start at genchi genbutsu. By engaging them, you can learn (or see) exactly what they do, how, why, and when. This gives you a much better idea for how what you’ve learned externally will fit in this context and serve to help or hinder this person.

Leanish – Yokoten

About those sources, there’s something we should say. Often people like to gravitate to experts and their “best practices” as they way things should be done. Why would we do it any differently? Those practices are the “best” way to do it.

Life is not so simple as to let us say that there is a single “best” way to do anything. That’s especially true when we’re talking about novel opportunities in a large complex environment.

Although not necessarily a “lean” idea, Toyota offers some wisdom about how to handle these scenarios. When they find a new way of doing things, they do not engage in standardizing people on the “best practice”. Rather, they engage in yokoten, which can be translated as “across everywhere”.

The idea is not to tell everyone that this is the way to do it, but to say that this is a way it can be done. Exposing people to the idea will give them a chance to see if it will help in their context. It may. It may not. It may also inspire someone to try something else entirely, which may itself become a subject of later yokoten. This engages people in acquiring knowledge from external sources but requiring them to think critically about the solution and their current situation to see if there’s a way to improve the standards.

Using Human Creativity

Intel is a company that made the transition from forcing “best practices” to a model of exposing people to new ideas and tapping into human creativity to apply these ideas appropriately in each context. This can be seen in the shift of their internal language from “copy exactly” to “copy intelligently”.

Fortunately for those of us in software, agile methods provide a way to copy intelligently. We work closely with all stakeholders, we deliver frequently, and we are always adjusting to make sure we’re delivering the most valuable solutions possible this week.

Knowing what we want to achieve In a year or two is nice. It’s critical to understand why and to know what we’re delivering this sprint.

Leave a Reply