The Architect´s Napkin

Software Architecture on the Back of a Napkin
posts - 69 , comments - 229 , trackbacks - 0

My Links

News

Article Categories

Archives

Post Categories

Image Galleries

Agile Process Reality Check

Let´s get real about software development: It´s never going to be a quietly flowing river. Never. And that´s why the current approaches to software development like XP, Scrum, and Kanban will always cause pain.

Their basic assumption is you should be able to isolate a team for a while to work on features. Leave it alone during an iteration or a sprint to complete a set of features, or at least sit still until the current feature is done.

Certainly that´s what we all want as developers: being able to concentrate on creating value by implementing new features or at least improving existing ones. Until we´re done.

Project reality seems to differ, though. And it does not just differ because Scrum or Kanban haven´t been implemented faithfully. Project reality will always differ because customers and users don´t care about our longing for being left alone.

Get real about emergencies

Software development is not like some factory production where orders are worked on in a smoothly flowing manner until fulfilled. Software development is more like an emergency unit in a hospital. It´s constantly under fire from all sides.

Requests are coming in at all times. Resources are always limited. That means a software team has to use triage (http://en.wikipedia.org/wiki/Triage) to determine what to do. Three request categories seem appropriate:

1.    Requests that must be answered immediately.
2.    Requests that should be answered soon. If not right away, then tomorrow is still ok, but not much later.
3.    Requests that can be answered at no specific date. Tomorrow would be ok, also next week, maybe even next month.

Category 1 is about rare bugs causing heavy damage with customers right now or in the foreseeable future; show stoppers so to speak. They need to be taken care of within a minutes or hours. Whether certain requests justifiably are categorized as show stoppers or not, is of no importance. Someone high enough up the ladder thinks a request is in category 1, so the team needs to react immediately.

Naturally category 1 requests should be rare. More than once a week seems problematic to me. Not because such interruptions are to be avoided, but because such urgent requests either hint at very poor software quality or an undue relationship with the customer base.

Category 2 is about most bugs. They need to be cared for pretty quickly, but not immediately. Bugs are a threat to any customer relationship. Customers rightly assume bug free software – with bug meaning an unintended deviation from what a software developer was trying to deliver. A bug is the fault of the development team so it needs to take care of it as quickly as possible.

Category 3 is about new features, feature change requests, and corrections due to uncovered misunderstandings or deeper insight. No life is at stake if such a request is not processed immediately. It can be put on a backlog for prioritization.

Any project not just started is under fire with all requests from all three categories. In an early greenfield project, requests might just fall into category 3. But as soon as customers/users have put their hands on some (early) release, category 2 and 1 requests will start to come in.

That´s a fact no software development process should deny or neglect. Right to the contrary any software development process should revolve around this basic fact of software development reality.

My conclusion #1: We need a software development process, which institutionalizes request triage.

Get real about uncertainty

At the heart of Agile and Lean is the realization that requirements are notoriously poor. As much as we invest in requirements elicitation… the result still is fuzzy. I´d even say: Customers cannot specify what they want, they can only recognize if that, what software development releases to them, is what fits their needs.

Customers are poor at a priori definition, but extremely good at a posteriori judgment.

As software developers we thus live in a constant state of uncertainty. We just don´t know if what we´ve developed really is what gets accepted by the customer. Did the customer define his requirements correctly? Are they complete? Are the comprehensive? Does the customer know at all what´s necessary to solve her problem? Have we understood the requirements? Have we come up with a solution matching our understanding? Will the customer accept our view?

Because of this uncertainty Agility/Lean advocates iterative development with delivery of completed features. Whatever get´s released to the customer at the end of an iteration has value to him; he can give feedback, because some requirement has been implemented.

How long until such a release? Two to four weeks seem the norm. Sometimes it´s just one week, sometimes it just takes as long as it takes for a feature. Iterations usually are measured in weeks, not months, not days or hours.

This seems ok – until iteration timeboxes collide with project reality. Any request of category 1 or 2 is likely to cause a delay. Such requests naturally are a nuisance for any process requiring quite time to work on a plan laid out for a couple of weeks.

My conclusion #2: We need a development process, which embraces the undeniable reality of category 1 and 2 requests.

But not only are timeboxes of several weeks in contradiction with daily project life, they also still do not really honor the uncertainty of requirements. Think of it: A day 1 of an iteration you start working on a feature. You finish it by day 4. But the only gives feedback at the end of the iteration, maybe on day 14 or 21. That´s a long time since you checked off the feature in your head as done and got rid of your mental feature state. The feedback loop is quite long even in today´s agile processes. On average it takes at least half an iteration until you hear back from the customer.

Also, during an iteration several features are implemented. This means, whatever change request the customer might have at the end of the iteration, it can possibly affect all features under development within the same iteration. The longer an iteration the more likely waste is created.

My conclusion #3: We need a development process, which allows for almost arbitrarily quick feedback from customers.

And then think of it: If requirements are so uncertain, why should a team deliver whole features at all at the end of a multi-week iteration? Neither does the team know, if it interpreted the requirements correctly, nor is it clear to the customer, if she really needs all that which she found important many weeks or months ago during requirements elicitation.

If a process tries to deliver as much of a feature as possible in a multi-week timebox, there is hardly any chance for the customer to say, “Stop! That´s good enough.” Current processes implement requirements in a very coarse grained manner. Their ideal is completion, arriving at Done for a whole use case or feature. That seems like a relic from the old waterfall days, to me. It´s not very true to the fundamental realization of Agility: Requirements are notoriously uncertain; we need to deliver often.

My conclusion #4: We need a development process, which allows customers to stop development of features at almost any percentage of completion.

Get real about evolvability

Before Agility the biggest challenge for software development was technology. We struggled to fulfill the explicit functional and non-functional requirements of customers.

The next big challenge then was correctness. Also a non-functional requirement, but not often explicitly stated. Customers rightly assume software to be correct, i.e. bug free. There is no excuse for a crash or an incorrect calculation.

Since then, though, the world has moved on. There are tons of technologies and tools at our disposal. There are several systematic approaches to increase correctness of code from reviews, to automatic unit tests, integration tests, and acceptance tests.

So I daresay today´s biggest challenge for software development is different. It´s harder to solve, because to assess the quality of our solutions with regard to it, is more difficult.

What I see as the biggest current challenge is maintainability or evolvability. We need to do a much better job keeping our code flexible. Cost is rising too steeply over the lifetime of a code base. Implementing a feature in month 3 of a project might cost X dollars, implementing it in month 18, though, will cost much, much more.

There are several approaches to attack this problem like Clean Code, Agile Architecture, or just tried and true principles and practices from 60 years of software development.

Strangely, however, current software development processes do not address the challenge. Neither Scrum nor Kanban are interested in code evolvability. They might measure a decrease in productivity, but they have nothing to say about how to improve the situation.

XP might be different in that regard. But then… how effective can it be to have list of principles and practices for high evolvability, when evolvability is not put to the test?

Yes, I think that´s a common blind spot of all current development processes: they do not really put evolvability to the test.

And why should they? Isn´t evolvability a matter of code design instead of process? Indeed it is – but alas there is hardly a measure for the quality of code base evolvability. Forget about LOC per method or class, forget about Cyclomatic Complexity, forget about afferent coupling etc. Those are just numbers that must be interpreted. And this interpretation is highly subjective and relative. Let´s get real: We can´t look at any set of measurements today and positively say, “This code has high evolvability.”

Checking the functional quality of code, checking it´s correctness, checking its non-functional qualities… that´s all different and comparatively easy. Checking evolvability, though, is hard. In the end the proof is only in the pudding. If a code base is hard to evolve, then, well, its evolvability must be low.

To check the fulfillment of functional requirements, execute the program. To check non-functional requirements, execute the program. To check the evolvability, evolve the code.

Sure, design/code developed using XP, Scrum, Kanban is put through evolutions more often than in a waterfall process. But my perception is, that´s not enough. There are so many teams trying to improve evolvability by applying Clean Code principles etc. – but the results are still suboptimal. From that I draw my last conclusion:

My conclusion #5: We need a development process, which addresses today´s major challenge evolvability head on by putting much more pressure on a code base through shortened evolution cycles.

Summary

Current development processes are a big step forward compared to whatever was the norm before. They have done a lot of good to the state-of-the-art of software development. To me the major contributions are:

  • We now know that requirements are very uncertain. The problem to solve is always poorly understood by customers and developers alike. To arrive at a solution we need to interact frequently.
  • In order to home in on a solution, a development team needs to deliver artifacts to customers on which they can give feedback. Software thus is delivered in slices (vertical sections), not layers (horizontal sections).

This corresponds to the first two items on the Agile Manifesto: Individual and interactions, and Working software.

However, I find the current implementations of the realizations of the Agile Manifesto lacking. Without doubt, they are well mend. But their implementation in many projects I´ve visited is strangely at odds with reality.

Teams are suffering even more from interruptions, because they now are trying to follow an ideal of not being interrupted. Customers are much controlled in their expression of how they think a project should continue. And teams have a hard time to assess how their code scores on an evolvability scale.

So my overall conclusion is: We need a next iteration of software development processes. XP, Scrum, Kanban are not the end, but just a beginning.

Print | posted on Wednesday, December 14, 2011 2:22 PM | Filed Under [ Thinking outside of the box Spinning ]

Feedback

Gravatar

# re: Agile Process Reality Check

I read your post, however I am not sure I agree 100% with it. For instance, the statement about scrum, kanban, etc that says.... "Their basic assumption is you should be able to isolate a team for a while to work on features". My underrstanding of agile is that this is not the objective. Yes, we identify context switching as a negative that impacts performance, and so try to reduce or remove it, but the goal is definately not to have a team working by iteself for extended periods of time with no disruptions (depending on what you define a while to be?). Also, I was not 100% sure what you mean by evolvability. Could you expand on this concept?
12/15/2011 7:36 AM | Mark Pearl
Gravatar

# re: Agile Process Reality Check

Hi Ralf,

this is a great article again. Thank you very much for sharing your thoughts. Your reality check overlaps my experiences. I can confirm.
The big question is how can we develop the quality of our software development processes further.

Personally I am a big fan of Scrum. If Scrum works or not very much depends on the current knowledge of various software development techniques. For me the biggest problem here are not the developers, but customers. Your article is focusing too much on developers.

Customers tend to neglect their responsibility. Especially if the customers don't have their own software development department. In my daily business I experience that customers have problems with the process quite often. They have difficulties to understand agile methodologies. Which responsibilities do the customers neglect? For example very seldom customers attend review meetings. Customers are almost never seen at estimation or sprint planning meetings. And what about end users? Scrum generally takes the end user into account. Customers and end users are usually different. In reality we talk very seldom with end users.

I think it was very good that agile practices like Scrum and others have been hyped by the media over the last years. Customers might think that agile is good for them, but they still have difficulties to implement the necessary customer-side processes.

Personally I am very much interested in how we can improve the partnership between the Product Owner and his development team on the one side and the customer on the other side.

One of the most important parts of Scrum for me is the retrospective meeting at the end of each timebox. The team is continously trying to find new ways to improve. Of course this also includes the way they could interact with customers as well. At least the team should place a particular focus on this over time.

-- Klaus
12/15/2011 9:04 AM | Klaus Stake
Gravatar

# re: Agile Process Reality Check

@Klaus: This article was supposed to focus on the developer. It´s the developer "suffering" from uncertain requirements. It´s the developer "suffering" from exploding entropy.

In the end however, it´s all about the customer. You´re right. It´s even more about the customer than XP, Scrum, and Kanban think :-)

The constraint on most projects is not the development team, but the customer. I´ll explain that in another article.
12/15/2011 9:38 AM | Ralf Westphal
Gravatar

# re: Agile Process Reality Check

@Mark: The goal of Scrum et al. is not to have a team work uninterrupted for extended periods? I´m surprised. Could you please show me a statement along that line in the literature?

Please note I´m differentiating between "interruptions" (request categories 1..3) and interactions. Sure, a team should be able to interact with the customer at any time. No question should go unanswered for more than a couple of minutes or hours if possible. That´s why Scrum puts so much emphasis on the PO and co-location is advocated by all agile processes.

But the team asking a question is different from a supporter comig in and asking the team a question, or some manager coming in and asking the team to quickly implement a feature change because he´s about to go golfing with a customer ;-)

I´m sure agile processes try to avoid the latter.
Nevertheless that´s reality. That´s part of the culture of most shops. That´s even part of their business model. "We are able to react very quickly to your requests."

For a long time I´ve tried to fight this "chaos culture". Now I´ve come to the conclusion it´s stronger than most teams are. According to Peter Drucker: "Culture eats strategy for breakfast."

So if a team wants to become agile it better not oppose this culture. Rather it should embrace it.

As for evolvability: If a software has features X, Y, Z today, and tomorrow it has X, Y, Z, and A, B, and then it has X, Y, Z, A, B, S, T... the software evolves. It goes through rounds of evolution. It changes (or more precisely: is changed) to adapt to a changed environment (customer requirements).

Changing software means changing its structure. Structural elements come and go, are changed, connections between structural elements are created, destroyed, changed.

When I talk about evolvability I mean it should be easy to change the structure of software to change its functionality or its non-functional traits.
12/15/2011 9:50 AM | Ralf Westphal
Gravatar

# re: Agile Process Reality Check

I think the key here is extended periods of time... I miss understood your point. Yes, the objective is to focus on prioritized items uninterrupted, and I agree, the reality is this is very hard to do and business does not always buy into it and always has exceptions and wanting their things done first... a strong product owner would probably help solve this problem. I also read in early literature of scrum a team having something they call a batman (who is there to put out fires, while the team focuses - I haven't seen much on this since then, but maybe because I am not up to date on this?). The reality is there will be a certain degree of chaos but we try to limit it to managable chunks... on a side note, personally I think Kanban is better suited to software that has reached this point of its life than Scrum is. Thanks for the post, made me think a bit!
12/15/2011 1:29 PM | Mark Pearl
Gravatar

# re: Agile Process Reality Check

actually agile approaches handle this pretty well, if you have a number of category 1 and 2 issues constantly disturbing development, then you need to spend some time purely driving your bug count down and addressing the source of bugs. Shorten your iterations. Always keep your software in a releasable state. Which should be much easier these days with the likes of mercurial / git etc.

A lot of this depends greatly on the nature of the software you work on.

A lot of the problem is really not about the process......its about design. Adopting agile doesn't mean people are going to be better at designing software. XP has some practices that can help you get better.

It's often overlooked, but agile got born out of 'culture of design' people who were passionate about the design of software who then evolved processes that suited how they go about crafting software....

Now, we get people who have no culture of design adopting the same processes and wonder why they aren't that successful.

If you look at the early days ( pre 'agile' ) of XP, 90% of the conversations were about how to design really really well and how to evolve designs.
12/15/2011 9:55 PM | Keith Nicholas
Gravatar

# re: Agile Process Reality Check

@Keith: So you mean it´s good Scrum or XP or Kanban practice to change iteration lengths often to accomodate changes in the environment? Or it´s good practice to interrupt an iteration to solve problems or "urgent requests"? Really, I mean "it´s good practice", not, "yeah, you can do it if you really must". So I mean such adaptions are part of (!) the definition of Scrum, XP, Kanban. I´d be very happy if you could provide me a literature reference for that.

Sure, many problems arise because software structures are not as evolvable as they should be. A process cannot help much in this regard. But it should try. As I said: "good design" cannot really be measured. Whether it´s good or not (in terms of evolvability) only time is going to tell. SOLID might be a guideline towards higher evolvability. But it´s just a structuring tool, not a measurement tool. You can apply all the SRP, SoC, SLA, LSP, LoD, DI you want - and still don´t know if the code really is evolvable. That´s why the pressure, the need to evolve needs to be increased.
12/16/2011 10:12 AM | Ralf Westphal
Gravatar

# re: Agile Process Reality Check

Good post! I totally agree on all three reality checks; emergencies cannot be seen as something exceptional, as they are rather the norm in the daily work for many developers. I like your hospital analogy, and we should indeed think of ourselves more as working at the emergency department than at the R&D-department!

Triaging can in fact be seen as an essential skill at my workplace, as everyone constantly have a long list of issues to attend to, and we need to prioritize case-by-case, customer-by-customer, or we'd lose a few of the "patients". I suspect that even if we magically stopped all new requests, we could probably work ourselves down the backlogs for a year or more until we ran out of work.

The development model therefore shouldn't just take the easy route ignoring these facts, and have us plan as if we don't constantly have emergencies!

As for the other two, I just recently wrote a post about uncertainty, that just like this post argues the inability of most customers to specify non-functional requirements. I also have a post planned about evolvability (or making your software "adaptable" as I put it), and agree that it is hard or impossible to measure this by tools, other than by watching the side effects; high code churn (lots of code changes needed for new features) and the steady rate of new bugs in the evolving code base, causing low productivity.

I'm not sure, however, that putting the code base under "evolutionary pressure" will cause the property of evolvability to emerge. I'm thinking this depends on the experience of the developers, as my experience is that the code produced by a team of inexperienced devs will just start to crumble under such pressure. Which is fine in the longer run if you want them to learn (the hard way) to make their software adaptable/evolvable, but will be problematic in the shorter run.

Whereas a more experienced team would build a more adaptable solution from the beginning, and will know how to refactor a code base adding adaptability where recent change requests show it is needed!
12/21/2011 12:31 AM | Martin
Gravatar

# re: Agile Process Reality Check

@Martin: Sure, putting the code base under pressure is not enough. Whoever is under pressure needs to know how to deal with it. He needs to have room for doing that (autonomy) and at least some basic capability.

And that´s my point: Any effort to gain autonomy (self-organization) or capabilities in order to write more evolvable code will not really succeed until they are really, really needed. Thinking about SOLID or whatever, doing TDD, refactoring, reviewing etc. is all nice and well - but it´s only tools and strategies. They´ll evaporate under the sun of the current business culture.

So the basic business culture needs to be changed first. That happens if you put Acceptance over specification and require a much higher delivery rate. Then and only then become tools and techniques inevitable, only then aren´t they just some nice to have but crucial to fulfill business needs. Only then budget for actually learning and implementing them will be allocated.
12/21/2011 9:36 AM | Ralf Westphal
Gravatar

# re: Agile Process Reality Check

"We need a development process, which addresses today´s major challenge evolvability head on by putting much more pressure on a code base through shortened evolution cycles."

I couldn't agree more. Have you used XP with iterations of 1 week or less? One of the reasons why I like Kanban is that it decouples cadence from the work itself.

What I would suggest you look into, if you haven't already, is the concept of Continuous Delivery. It was originated by Jez Humble, I believe.

I know a couple of companies whose process involves pushing a feature to production as soon as it has been deemed completed by the developer and product manager. To do that safely means that you need to use a lot of practices straight out of XP such as automated using and acceptance testing, and Kanban is a good fit for visualizing the workflow.

Another place to look is the nascent Lean Startup movement, which spends a lot of time addressing your conclusions #3 and #4.

With regards to your first point about ignoring emergencies, when I coach teams I tell them that there are problems that simply have to be addressed immediately. I also tell them to use a triage approach. However, the "leave the team alone during the iteration" concept was a late 1990's reaction to constantly changing priorities and scope creep. It's much easier to say, "Don't change the contents of the iteration" than it is to say, "Be pragmatic about accepting changes to the contents of the iteration". After all, one person's "pragmatic" is another's "foolishness". :)
12/22/2011 3:27 PM | Dave Rooney
Gravatar

# re: Agile Process Reality Check

@Dave: Have you looked at my article on Spinning? That should show you where I see XP practices and CD.

As for Kanban: Kanban is a crutch ;-) As already Toyota said, using kanbans is not a goal, but just a temporary means to an end.

The problem I see with Kanban is that it does not deliver reliably. Work items take as long as they take. Devs are admonished to make them pretty much of equal size - but that´s hard as long as you think of larger chunks.

Spinning solves this by strictly saying "work items" (or feature slices) should be only of size "1 day". What can be delivered until the end of the day can be estimated pretty accurately. But what goes beyond a day or two... that´s very hard to estimate.

Spinning is about smallest meaningful batch sizes and constant flow.
12/23/2011 9:20 AM | Ralf Westphal
Gravatar

# re: Agile Process Reality Check

@Ralf,

"As for Kanban: Kanban is a crutch ;-) As already Toyota said, using kanbans is not a goal, but just a temporary means to an end."

Kanban (capital K) is not the same as kanban, the board used by Toyota.

"The problem I see with Kanban is that it does not deliver reliably. Work items take as long as they take. Devs are admonished to make them pretty much of equal size - but that´s hard as long as you think of larger chunks."

Yes, I agree with that. However, that's just the starting point - the team is expected to look for ways to improve throughput.

"Spinning solves this by strictly saying "work items" (or feature slices) should be only of size "1 day". What can be delivered until the end of the day can be estimated pretty accurately. But what goes beyond a day or two... that´s very hard to estimate."

I absolutely agree! Read my Fibonacci Must Die blog post. :) Although, having spent the last two years coaching in the telecom industry with unbelievable masses of legacy C/C++ code, I can understand why they say that a 1-day feature slice is impossible. I don't agree with them, but I can understand why they would think that. ;)

"Spinning is about smallest meaningful batch sizes and constant flow."

Yes - again we're in violent agreement!

I'll have a detailed look at your Spinning concepts later on. They look interesting at first glance.

Dave...
12/23/2011 3:44 PM | Dave Rooney
Gravatar

# re: Agile Process Reality Check

@Dave: I mean kanban (lower case). The ticket system. That´s what is to be overcome.

A kanban is needed when there is a lot of variation in processing time. But when batch sizes are small and the same... then you don´t need kanbans. That´s what Spinning is about. Chunks of variable size are coming in all the time. Whether they are produced to be stocked in a backlog or are delivered ad hoc by support is irrelevant. Spinning is not concerned with the source of the system change requests. They might not even be under control of the dev team.

But the dev team can chop and slice the requests to its needs. That´s what´s done first in Spinning. Triage, slice, understand the requests.

Once requests are sliced and diced and are of the same size Spinning takes a bunch of them and plans implementation. Implementation then takes a day to fully implement one or more request slices. So what comes out of the implementation and checking stages is a constant stream of request slice implementations.

They are supposed to get Accepted on a daily basis to truely move forward the project and get feedback. But then happens to the Accepted increments again is not a matter of the team. If the customer wants to batch up the increments to push them to users only every couple of weeks, then that´s fine.

Spinning is the fast turning cog in the middle of the development process.

I sure hear "We can´t slice down requirements into 1 day increments!" all the time. But I don´t agree. Teams haven´t learned to separate learning from production, they haven´t learned to separate spikes from production, they haven´t learned to use test benches to offer functionality to the customer.
12/23/2011 7:18 PM | Ralf Westphal
Post A Comment
Title:
Name:
Email:
Comment:
Verification:
 

Powered by: