In this article, part of my series explaining better ROI from software development, I continue to look at Agile Software development.
In my previous article I talked about the Agile Manifesto statement.
In this article I look at the principles behind the Agile Manifesto.
I’ll look at each section in turn
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
I'm all about great ROI on your software development investment - and this statement is just superb for me.
By putting this principle front and centre I’d hope this emphasises that this is very much foremost in the creators mind.
It is very easy to dismiss ideas from Software Development as “gold plating”, “overkill”, etc. Thus I feel this first principal is a great leader. Hopefully as we go through the principals I can convince you of the rationale behind them and how they link back to that valuable software.
There is little value in software that makes only the Software Development team “satisfied” (although I do believe it is important that they are). It is the customer, in this case you, that needs to be satisfied that the software you are getting is valuable.
The guys are putting you on the throne … enjoy it.
The early and continuous delivery speaks of trying to establish as much of that value for you as quickly as possible. Rather than deliver the entire application, what is the smallest part that is useful and can generate value?
The general belief is that most users only use 10% of the functionality within Microsoft Word. Why wait until you've developed the other 90% before getting it out there and in to use?
I’d like to introduce the concept of Minimum Viable Product (MVP) at this stage. The whole principle behind this is to look at the smallest, simplest thing that you can do to prove your product has value. In the case of the Microsoft Word example, you could certainly be getting significant value from well before its 100% complete. MVP will make a lot of appearances in this article.
“Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.”
I talked about change in the last article – basically it is inevitable.
Swim with the current, not against it.
“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”
The sooner we deliver the software, the sooner you can be firstly validating it is what you want (reducing the chance of wasted effort) and secondly be getting value from it.
Think about MVP, if you can be getting value from a subset then get it out quickly.
I’d see quick feedback as part of that value. If the development team is spending time building the wrong thing (can, does, will happen) – it is a lot more valuable to discover this two weeks in – rather than 2 years.
“Business people and developers must work together daily throughout the project.”
The closer that the requester and the deliverer are, the better quality the product AND the cheaper it will be to produce.
If there is a continual dialogue then any variance from the expected (the building of the wrong thing I talked about above) can be minimised – reducing overall cost. Note that I say minimised; we are still human and can make mistakes or find a better way as we work with the request and learn more.
Having good solid collaboration reduces waste – such as having a development team idle why they wait for a response. It also allows for the reduction of the unnecessary by-products (such as unnecessary documentation) if the two parties can communicate directly.
Again, solid ways of reducing costs & maximising ROI.
“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”
In one of my first articles, I referenced Deming who said that 94% of the responsibility for performance was with the system. This only allows 6% for the individual to effect.
So when we say the system; we are talking about the environment, structure, support, etc – anything that helps (or hinders) that individual.
If you don’t know what in the “system” is affecting your development team; talk to them. Talk to them often. If you’re creating a safe environment (they aren't in fear of being fired for raising criticism) then you’ll get good feedback – even if it is slow to start.
The more you work on any feedback – and be seen doing so – the more the team will engage.
This really helps to engage people’s Intrinsic Motivators. They feel they have a voice. They feel they have “skin in the game”. They take greater enjoyment from it. And they become self motivating.
And of course the mention of “trust”; which I highlighted in the last article.
“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
This is probably one of the easiest ones to understand, but the one we've traditionally put so much effort into avoiding.
Think about any of the following activities as introducing a “tax” on your development costs:
Some taxes are small, some are greater - the total tax will depend on your team.
In an ideal world, you’d put all the people involved in the project in a team space where they are free to communicate directly and collaborate with minimal distractions. The further you are away from that, the more tax you are paying.
“Working software is the primary measure of progress.”
Again, back to the principal that software development should be producing valuable software. That is it’s purposed. Everything else is a by-product.
Having good documentation is a by-product.
Hitting targets on a plan are a by-product.
In financial terms;
“Turnover is vanity, profit is sanity, cash is a reality”
“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”
Taylorism (“Principles Of Scientific Management”, Fredrick Winslow Taylor, 1911) heavily promoted the use of External Motivators to increase production.
And this has largely defined the reward/ punishment management culture.
This is acknowledged as being a poor motivator for knowledge workers.
But it hasn't stopped many managers using reward, punishment or a combination to drive individual workers beyond a sustainable pace.
And while this may produce benefits in the short term, they invariably produce longer term debt in terms of an individual’s performance, motivation and quality. There are plenty of studies that show that working overtime is no more effective (and generally less so) than maintaining a steady state.
Think about this as a steady line rather than the peaks and troughs you’d see with an inconsistent working patterns. The output over time is invariable going to be no greater – but you've incurred the impacts to performance, motivation and quality – all things you will pay for pushing beyond the sustainable pace.
If you are finding that you need to push for “spike” work; take a step back and look at the organisations and how it is planning things. Generally you will find that something outside of the development teams control has created the problem – common examples:
This is very much an example of the system, as Deming described it, having a majority impact on performance.
At this point you maybe screaming at your screen; demanding how that helps when the business desperately needs it done quickly.
And you’re right to ask … calm down, it will all be fine.
There will be times where something urgent does occur. And with an engaged motivated team they will take that in their stride and dig the company out of the hole. This comes back to triggering the Intrinsic Motivators – where the team are bought into the company’s direction and aims. You see this quite a lot in start-ups where the team can see the direct effects of their efforts.
This should however be the rarity rather than the norm. And when I say rare, I mean once a year. Otherwise all you are doing is burning out any Intrinsic Motivators you might have built up.
You can also generally help yourself by talking to the team about the problem and asking them for ideas – don’t automatically lead with overtime. Certainly don’t lead with “without this, we are all out of jobs” – you need an exceptionally strong relationship with the team for this not to result in immediate CV updating.
There are also techniques that can help in a bind. MVP for example, is your friend.
“Continuous attention to technical excellence and good design enhances agility.”
Very much in the same vain on MVP is YAGNI – You aren’t going to need it.
Basically put, if you don’t need it now, defer the effort.
The smaller and more focused a piece of work is, the quicker you are likely to have it – ready to prove if the software is valuable.
This principal is a hint to the entire project team – both the business and the development team. It is very easy for both parties to add stuff they think is useful. When in truth they are more efficient to focus on the minimum – get it done, review it (be that internal review or customer feedback) and then adapt.
You simply may find that the killer feature you expected to make you millions has no market. Better to find that with two weeks investment rather than 2 years.
That all being said; there is a balance that needs to be drawn.
Some things should really be thought about as you build them – security and scalability are the two obvious ones. These can be notoriously difficult to retrospectively add to software.
Security for me should be baked in. It is something that should be considered part of the tick list to say if even your MVP is ready. I intend on talking about Security and it’s every growing importance in a future Article.
Scalability is a bit more tricky. Scalability is how well your software handles going from 10 customers to hundreds, thousands or even millions. How much you focus on this in the early days depends on the expected plans for the software. If it’s only ever going to be used by 10 people you can largely ignore it. If however you are building the next Twitter then it probably should at least be a consideration from day 1.
Ideally you do enough to make it practical in the future – but not too much that you've wasted a lot of effort if your idea simply doesn't take off.
“Simplicity--the art of maximizing the amount of work not done--is essential.”
Basically minimise the work that is causing no value.
Two things you need to look at here.
The value stream of the end to end process – what tasks are adding value, which aren't. Minimise those tasks that aren't adding value, maximise those tasks that are. From experience there will generally be quite a lot of “fat” around keeping the management chain happy. If you can change the mindset to trust in the team and encourage the Intrinsic Motivators, then you can generally cut out quite a lot of non-value adding activities.
The other is MVP/ YAGNI – reduce the amount of work and make it simpler. All saving time and thus investment.
“The best architectures, requirements, and designs emerge from self-organizing teams.”
You are employing knowledge workers. Let them think.
While you may be great – it is unlikely that you are cleverer than a team of people (even I, with my giant ego, admit that). You’re paying them to think – why do it for them.
Why keep a dog and bark yourself?
More minds on a problem will deliver a better result.
That doesn't mean you shouldn't be involved. Rather you change from management to coaching. You help the team improve themselves.
“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.”
The idea of Kaizan continual improvement isn't new – credited to the Toyota manufacturing process where they are continually improving the system – it can always be improved.
In software development, the entire team should review itself on a regular basis and look for improvements to be better.
Again, this is a greatly positive place to be – the team are constantly looking for improvements in how they deliver valuable software.
This is the pinnacle of the team being driven by their Intrinsic Motivators.
Key here is to listen to the team and take their ideas on-board.
Ok, we've covered a lot of ground. The word count so far is pushing 2,200 – about twice the size I’d generally want to use for an article, so let’s summarise the ROI benefits available to you with Agile:
All of these can add up to a significant improvement to ROI.
Agile is a mindset.
It isn't however a prescriptive method of working.
Think of it like a vision statement. It sets out the principals under which you operate.
In the operating of your business you will have a business plan that supports that vision. You will then have procedures aligned to that business plan.
The Agile Manifest sets out the overarching direction of travel – thing of it as a compass.
You will then generally employ a development framework that adheres to the principals of Agile. By far the most populate of these is Scrum … a framework that guides your team along the Agile direction. I’ll look at Scrum in more depth in a future article.
You will then have prescriptive processes on how certain things should be done. These are you’re fine grained travel directions. In development, you will see this as complimentary practices that plug into the framework.
These are places where each team can, and probably should, differ. Each team is individual and some things will work better for them than others. It will be part of that team’s reflection to identify what works and what doesn't. Again I will pick out complementary processes that I feel are beneficial in future articles.