The team I’m working with at the moment is at a formative stage and has come up with a set of principles to collectvely aspire to:
Ship Something
Our overriding goal is to add value to the business as quickly and effectively as possible
Done
Our definition of done is when it is live and has been thoroughly tested
No hidden work
All work items should be tracked on the board
Unit Tests
All new or changed code should be thoroughly unit tested
Boy Scout rule
Leave everything in a better condition than you find it
Take risks
We are prepared to take risks with new technology and ideas
Be a tester
It’s everyone’s responsibility to make sure all work is thoroughly tested before being released
The Principles behind the Agile Manifesto
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity–the art of maximizing the amount of work not done–is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
The Five Principles of Lean
- Value – specify what creates value from the customer’s perspective.
- The value stream – identify all the steps along the process chain.
- Flow – make the value process flow.
- Pull – make only what is needed by the customer (short term response to the customer’s rate of demand).
- Perfection – strive for perfection by continually attempting to produce exactly what the customer wants.
The Seven Principles of Lean Software Development
- Eliminate waste
- Amplify learning
- Decide as late as possible
- Deliver as fast as possible
- Empower the team
- Build integrity in
- See the whole
The 4 Sections and the 14 Principles of the Toyota Way
I. Having a long-term philosophy that drives a long-term approach to building a learning organization
1. Base your management decisions on a long-term philosophy, even at the expense of short-term financial goals
II. The right process will produce the right results
2. Create a continuous process flow to bring problems to the surface
3. Use “pull” systems to avoid overproduction
4. Level out the workload (heijunka). (Work like the tortoise, not the hare)
5. Build a culture of stopping to fix problems, to get quality right the first time
6. Standardized tasks and processes are the foundation for continuous improvement and employee empowerment
7. Use visual control so no problems are hidden
8. Use only reliable, thoroughly tested technology that serves your people and processes
III. Add value to the organization by developing its people and partners
9. Grow leaders who thoroughly understand the work, live the philosophy, and teach it to others
10. Develop exceptional people and teams who follow your company’s philosophy
11. Respect your extended network of partners and suppliers by challenging them and helping them improve
IV. Continuously solving root problems to drive organizational learning
12. Go and see for yourself to thoroughly understand the situation (Genchi Genbutsu).
13. Make decisions slowly by consensus, thoroughly considering all options; implement decisions rapidly (Nemawashi).
14. Become a learning organization through relentless reflection (hansei) and continuous improvement (Кaizen).
James Shore recently wrote an article on agile mediocrity:
“In sales, they teach that the first objection is often a false objection–misdirection rather than a real concern. “Does Agile scale?” can be one of these false objections.
I wasn’t really being asked “Does Agile scale?” (By now, though, we know the answer: yes.) What I was really being asked was, “Does Agile work in large, dysfunctional organizations? Can I keep doing all of the ineffective things I’m required to do and still say I’m Agile? I can’t have a co-located team–it’s out of my control. I can’t have active, involved product managers–they’re too busy. I can’t create cross-functional teams–it would disrupt our reporting hierarchy. How does Agile scale to mysituation?”
It doesn’t… at least, not well. Welcome to Mediocrity.”
I’m slightly more sympathetic than James (who has clearly become frustrated seeing the same pattern over and over again) having worked in a large organisation adopting agile and see how we can quickly get to agile mediocrity, but struggle to go any further. Typically the catalyst for change is some enthusiastic developers and a forward thinking dev manager bold enough to take a chance that the Agile gumpf these guys keep going on about might just solve a few problems. This has some success, which gets jumped on by higher management who are lured in by the buzz and enthusiasm and it gets rolled out to other teams, however then it starts hitting walls. Firstly is the resistance within the department (and this is relatively easy to get over), but then it becomes clear (to the agile teams) that to achieve real results change needs to occur further afield and here’s where it all starts to seize up.
Agile is a bit like dropping a bomb in an organisation in that it creates shock waves which spread outside the IT department and have the potential to change the entire organisation (after all agile is the child of lean production which can be applied everywhere ). The problem is the wider the shock waves spread the more difficult the change is. Large bureaucratic organisations will always suffer from more inertia and change will be slower. I guess here is where a lot of people might get frustrated and start saying things like “it doesn’t scale”. The big mistake is blaming agile for your organisational inefficiencies. It’s not the fault of agile that your company is a lumbering old dinosaur that shares the characteristics of a supertanker when trying to change direction 
In my mind this is largely a management problem. They’re often very keen on Agile when it doesn’t mean they actually have to do anything. A self-motivated software team trying to make things better? Great! Restructure the organisation so the delivery team is sitting and speaking with the customer, employ in-house testers and allow time for learning in working hours? Mmm not so attractive.
It’s not sufficient just to roll out Scrum or install a Kanban board. As I’ve said similarly before to succeed with agile you need to look past the latest fashionable methodology and really understand the underlying principles. The Agile Manifesto and the principles behind it would be a good place to start.
Pragmatism is very important in software development, but that’s very different from not understanding why following patterns and practices is a good thing. Sometimes you have to get a piece of work out the door to hit an important deadline and make some money, but this does not justify doing it all the time as you’ll eventually end up with a big ball of mud.
On to the analogy. If you do forsake quality for speed, understand what you’re doing is buying your software on a credit card. Eventually you’re going to have to pay it back, along with the interest that will have accrued. If you leave it too long it will become unmanageable and you will go bankrupt (rewrite?!). There’s a very good reason why it’s called technical debt.
OK, sometimes (and really not as often as you think) you will have to do this, but make it clear to everyone involved that you will have to pay and the sooner you pay the less it will cost.
Jason Gorman recently tweeted “Programming as a life skill? Discuss.” Well how about “don’t spend what you haven’t got”? The world is in financial meltdown because people have been borrowing far more than they can realistically repay. Personally I don’t have a credit card or any debt for that matter. I believe that if you want something you have to earn it.
Writing poor quality software to get it out the door fast means you’re not paying for it’s true cost. Fine, just don’t stick your head in the sand and pretend the debt will go away because you’ll be the one paying for it.
