I was asked recently by someone I greatly admire and respect, “Wouldn’t you rather plan for risk than react to the circumstances that befall your project?”
At the time I was stumped. Yes I guess I would, but we can’t see everything can we? At least I can’t.
In reflection my answer is: I would rather do both. See and plan for those risks I know and use a daily scrum-like meeting to capture what I cannot plan for.
What are your thoughts?
Introduction
Container shipping transformed the way goods were transported across geography and channel. Instead of having many diverse payloads in differing container configurations for different modes of transport; a standard was defined for a rectangular container that could, through a set of standardized connection points, be bolted to ship, train, or truck. The result of simplifying the container configuration meant that transferring cargo between modes of transport became easier, shipping times were reduced from port, to rail, to truck. Handling and management costs also went down because there was less variation in the cargo.
In the same way agile is standardizing the time-boxed delivery mechanism for software development. Widely, today, the iteration is seen as that container. In the majority of agile shops the 2 week iteration with a daily stand-up, front end planning session, and back-end review session; is the norm. The channel of delivery might be scrum, xp, lean/kanban, or some hybrid of these. The choice of which channel to use is deeply dependent on the business environment surrounding the software shop. But regardless of the rails the iteration rolls over; it has become the choice for time-packaging completed requirements.
What are the implications of this to business and development groups? What changes does this standard for team delivery impose/challenge the modern organization with?
Finance and Accounting
How capital projects are financed for internally used software has not followed the train of direction the iteration has brought forth. Traditionally, project estimation is bottom up and we derive funding by establishing a level of effort ( LOE ) across the project, with some breakdown into work packages. Iterations have the capacity to be the bricks of capital financing upon which projects are funded.
The challenge to IT finance groups is to derive the cost accounting for an iteration ( essentially a two week productive work team ) and then establish capital planning policies and procedures that estimate, plan, track and account by those iterations.
At first blush this sounds simple. Why not just figure out the appropriate team composition: say 3 developers, 2 qa folks, 1 product owner and 1 team leader. 7 people X 50 hours a week = 350 hours X $70.00 per hour = $24,500.00 per iteration. So now we just need to figure out how many iterations we need. Right?
But wait….
What if I need a DBA, Infrastructure Person, or support analyst engaged? How about software licensing, pc costs, PTO ( paid time off ), employee rates vs consulting rates, and other indirect costs? What about the funding mix for any iteration? Surely not all of it is CAPEX. Some of it may be OPEX. But what mix of a typical iteration should be OPEX vs CAPEX? Should certain iteration models exist depending on what the team is doing?
These questions begin to explode the subtlety. By standardizing delivery on iterations, the finance group and IT leadership can standardize the IT shop and its costs. Should success be achieved, CAPEX and OPEX planning should become less complex and more routine; fundamentally reducing the infrastructure, roles, and process associated with this annual event while simultaneously establishing a standardized point of accountability and process planning.
This also changes the very nature of estimation from detailed to relative. We’re now looking at value creation, rather than cost control. The challenge back to the business will be how much value is derived at various cost points and at what point cost becomes too much. Project costing becomes a negotiation toward shared value based on relative targets achieving a defined set of NPVs.
Management and Leadership
In an iterative organization the control, power, and operation are at the iteration team level. Influencing those groups will require a leadership and management structure that is comfortable with fluid and mobile adaptation of resources to project needs. Leadership truly begins to shine in this type of paradigm. No longer dependent on a static formal organizational structure to derive power, the real leaders will begin to exert influence over these mobile iterative pods.
Those succeeding in such an organization will be gifted in the art of servant leadership, coaching, influence, and mentorship. Command and control will be reserved for extreme HR issues alone.
Innovation
Iterations also change the shape of R&D and new innovative initiatives. Iterations demand transparency, accountability, and risk reconciliation. The iteration opens things up and standardizes the cycle of delivery. To many this may stifle the idea of invention and creation by putting it on a disciplined cycle, but does it? In plain english: business demands a return on its investment. Research for research sake is a university concept.
Org Charts & Structure
How is organizational structure affected by the expansion of iterations? While most IT shops today are familiar with the matrixed organizational structure, the iterative organizational structure groups teams into standardized pods for delivery.
The pods would favor generalists who are good at a multitude of IT functions but perhaps are not perfect at all aspects. This structure would be fluid and adapt to organizational need. An example iterative structure is below. In this way the iterative POD is responsible to the director as a team. All individuals in those pods report to him/her.
Personal Career Growth and Development
Iterations have already had an enormous influence on personal career development at software shops. It’s not enough to be just a code whiz. Iterations place emphasis on teamwork, personal accountability, and decent communication skills. Flexibility is also a key aptitude sought in the iterative individual.
Good delivery PODs are ready made hired guns. Teams of professionals that could potentially write their own engagement. In this way staffing by placement firms and consulting groups changes from individual placement to team sourcing.
Summary
The transformation of the shipping and distribution industries to containers wasn’t a simple overnight change. Standardization requires upheaval and new ways of thinking, approaching old problems. Organizations that adapt to the standard IT container and see it as more than just a ‘development thing’ are best positioned to yield the benefits that this change could bring.
I’ve been hanging out and posting at the ASPE SDLC blog. Yes…I have their permission to do that. Geesh. Check em out Gilbert:
Six Things To Avoid When Reporting Project Status – Project status is about the facts and your strategy to address and manage those facts.
This Daily Standup Is a Joke – This article details some challenges associated with daily stand-ups and some potential strategies for dealing with these.
An Axiom of Project Success – What’s the common thread to project success? We’ve seen projects that should have died. We’ve also seen projects fall apart that seemed like they were in the bag. This post attempts to nail the overriding factor.
That’s Great…But How Does Agile Benefit Our Shareholders? – Selling agile to key leaders in your organization takes more than just a thorough understanding of story points, and time-boxing. This post brings it home for those wanting a bigger bang for their agile swang. Whatever that means.
Here’s some of my 2012 predictions, ok…. guesses:
1. Real Options will become a bigger part of planning software and application development projects. Unlike other projects we’re not discounting a straight stream of cash flows. We’re discounting a complicated tree of decisions.
2. Scrum Will Breakup – The forces that made it popular will rip it apart.
3. Agile’s Luster Becomes Rustier – The torrent of zealous marketing and hype will take its toll on agile. There will be increased backlash and doubt through 2012.
4. The Kanban Rock Will be Turned Over – Executives will look into Kanban for software development and ask “Where’s the value here?”
5. Managed Service Providers Will Enter Software Development – Utilizing contingent labor available through sites like Guru.com they’re finding ways to drive down the costs of software development for cheap, simple, fixed bid projects.
6. Agile 2.0 Bandwagon – The agile 2.0 proponents will attempt to reboot life into the “movement”.
7. Startups get faster, leaner – Driving towards continuous, high quality delivery…some startups will take Eric Ries Lean Startup philosophy further and push tool vendors, or even create their own tools.
8. Tools Start To Takeover – We may have stretched the limits of new practices and patterns. Time for the tools crowd to take over? NoSQL and the rejection of OOD&D as too complex for most development efforts may yield simpler higher quality tools.
I never can seem to round out my lists to 10. How do other writers do that? Oh well. See you in the new year. 🙂
Over commercialized, overused and mis-applied the word “agile” has become synonymous with being better, faster, and cheaper. The hype around the “A” word is nonsense. Most of the software vendors, consultants, and marketers plastering agile on everything are simply capitalizing on the popularity of some ideas that aren’t even correlated with what their selling.
Agility is not a panacea. It’s not a software tool. It’s not a product you can buy. To my opinion it was a state of mind, a way of approaching problem solving.
It’s now lost that meaning. It’s original luster is awash in a sea of hyperbole and advertising. When someone says they’re agile or they practice agility….I no longer know what they mean. It might be that they read a book, they use some self-professed agile software tools, they have a poker planning card set, they bought a CSM certification, or they recently attended some conference on agile software development. Stop Agilizing Everything was written in protest to the fluff, and monetization of agility.
Will it stop? I doubt it.
Instead it will kill itself through abuse. Eventually it will become the worn fad of the day. In disdain and disgust we’ll turn our backs on the “A” word and seek something with more substance.
Introduction
Scrum, probably the most widely adopted agile software development practice, is cracking up. The signs are evident and this article discusses the trend and what it means for agilists today. If you practice scrum, are thinking of using it, or have used it in the past you’ll find interest in this article.
Oh yeah? Prove it!!!
It’s a truism that rapid growth and popularity put a strain on organizations, movements, ideas…….or ,more fundamentally, the people comprising these very human vehicles. As an idea ferments and then exponentially amplifies to encompass a wider politic of devotees and admirers there is the impending fog of dissent with the origin, the core. From this comes splintering, debate and eventually more novelty and innovation.
Fine, but what about direct evidence for the rift in scrum?
03/05/2009 – Scrum But…Test. Jeff Sutherland.
09/15/2009 – Ken Schwaber resigns from Scrum Alliance
06/15/2010 – Ken Schwaber establishes Scrum.org
04/20/2011 – The CSM certification wars
07/26/2011 – Forrester calls Water-Scrum-Fall the norm
08/02/2011 – Bloggers Suggesting Scrum Variations
10/06/2011 – Scrum Extensions announced – allowing modification to basic scrum.
As the agile movement hybridizes and evolves scrum is feeling the brunt of this pain. The forces of hybridization are ripping scrum into distinct camps whose views are aligned with their respective organizational needs. Who are these camps and what will ultimately happen to scrum as this spider web is tugged from it’s anchors?
The Camps
The Enterprise – Most enterprises don’t build software as a core part of their operations. Projects here are usually centered on delivering some base set of functionality for a fairly fixed price. Stability and low cost of operation are prized. The organization doesn’t usually see this as an investment…but as an expense to be managed and tracked. The pressures enterprise software development groups face at the capital planning phase and the release phase have sculpted the Water-Scrum-Fall that’s prevalent.
The Software Companies – In contrast to the enterprise, software companies build software as their core product. It *IS* their operation. Software companies see their products as an investment and it’s life cycle is fairly unlimited, or at least tied to the life-cycle of the company. Pure scrum works in these companies fairly well. There’s usually still pressure to reduce the number of production releases but on the planning side managing features in a backlog fashion is workable, even preferable when you have a product that has a potentially unlimited lifespan.
The Startups – Startups face a different set of pressures from their venture capital investors. The need to rapidly introduce new features and create value to customers and investors by gaining a competitive advantage quickly is paramount. Startups are tearing scrum towards the Lean Startup methodology professed by Eric Ries. The focus here is continuous delivery of new software: stability be damned. Usually these startups don’t build software that’s mission critical or life threatening.
The Purist Methodologists – Among these are the various scrum trainers, agile coaches and general agile philosophers who profess a puritanical approach to scrum. Their insistence on a dogmatic approach to scrum are rooted less in practice and more in theory.
What are they doing to scrum…where are they taking it?
These groups are doing what’s natural. They’re catering scrum to their practice and profession of application life-cycle management ( ALM ). But this tug of war for scrum’s future is changing it. Instead of a simple, one-size fits all methodology, it’s becoming a framework of patterns & practices.
You can see this through the introduction of scrum extensions, which is a natural way of recognizing the various groups that have adopted scrum in some fashion. With scrum becoming an umbrella concept, it’s importance is melting away. It will devolve and eventually disappear. Instead the extensions, much like design patterns in software development, become the value added pieces that development teams will use and rally around. Each camp will likely pool certain extensions, patterns as their ‘methodology’. In time, these flavors of scrum will tear it completely apart.
Summary
Scrum’s popularity will likely be its undoing. But is this something to be avoided or stopped? Hardly. Hybridization and evolution of scrum is a natural process that is both pragmatic and necessary. Jeff and Ken’s baby is growing up and leaving the agile house. The original agile manifesto signatories accomplished their mission; they broke the one size fits all ALM world down. The new heterogeneous landscape of practices and patterns, while less clean than the bi-polar world of agile vs waterfall, is primed with greater opportunity for innovation.
Among the aroma of fruit cake, hot cider, and sub-zero temperatures Santa Claus announced today that his North Pole Workshop would switch to using agile practices in toy production. Santa sighted a number of reasons for the change, among them:
According to Santa, “We’ve analyzed this decision for some time and it became clear that change was needed after re-reading little Timmy Todsnockerdellturtlefoof’s complaint letter from last year. Instead of receiving a bicycle, as stipulated in his toy list; he got two fake icicles.”
The well publicized failure last year to meet the requirements of Timmy’s wish list was not the first time Santa’s North Pole Workshop hadn’t delivered, but in this day of social media and instant updates; the story took on a vicious viral characteristic….hitting #1 in the tweetosphere for a full month with the hash tag: #TimmyTodsnockerdellturtlefoofGotIcedBySanta.
When asked what type of agile practice the workshop would be adopting, Santa replied: “Scrum. It’s well known, proven, and being used in some isolated corners of our workshop today.” Some muted ‘boos’ could be heard from the audience.
Santa went on to say that Rudolph The Red Nosed Raindeer would head up the agile transformation of the North Pole Workshop in conjunction with an outside agile consulting firm to be named later. That development confirmed for some that Rudolph was next in line to take over The North Pole. Rudolph was on hand to comment to reporters after the announcement:
“We’re looking at one of the big 5 consulting firms, but we haven’t ruled out the smaller players. Look, what’s important here is that we get to done. I have a nose for this kind of thing. I’m not a dreamer..I’ve been a servant leader for a long time…I realize this transformation isn’t going to happen overnight, there will be pain and there’s a lot of existing process and procedure that will have to….well, frankly….go away. But, one step at a time. I expect we’ll have a more detailed plan in May or April. Talk to me then.”
Reactions among the North Pole elves was varied. One older elf man pointed out that Santa had to be dragged “kicking and screaming to the decision. He wasn’t on board at all. Rudolph, Frosty, Mrs Claus and the Yeti really had to sell him on it. When they broke out Timmy’s letter to remind Santa of the increasing defect rates in his shop….he went ballistic. I mean he really lost his cookies. Then the Yeti put his foot down. I think Santa knew what that meant.”
Others, like a younger elf woman, had a different opinion on the switch to agile: “I’m fine with the whole agile thing, but I guess I don’t understand why they chose Scrum? I mean….from what I read XP is way better and more applicable to our environment. I really don’t think the elves, particularly the older ones, will like daily stand-ups. I mean most of them can barely wake up every day….let alone stand up.”
Still another view was held by Donner, “What about Kanban? No one’s talking about Kanban, but in the reindeer house we use it all the time to limit HIP ( hooves in process). I bet Rudolph moves us there. I think there’s going to be a power play here between Santa and Rudolph. It’s a battle that’s been brewing for centuries.”
“Give me a break. Agile? Really, let’s knock off the buzz and hype. So we goof up on a few thousand toys out of the billions we make a year. How’s agile gonna solve that? I don’t get it. I guess I’ll ride it out and see where this goes. But limiting HIP in the reindeer house has done nothing but give some of us more time on our hands. I don’t think that’s what Santa wants.” said Blitzen.
Frosty, while at the announcement, declined to make any official comment but did say that he favored a balanced, pragmatic approach, one that would focus on the workshop’s needs rather than a dogmatic approach.
Mrs. Claus had this to say: “Rudolph is very bright. I know he’ll make this work. He knows where he’s going.”
Strangely, the Yeti, was not present. But his footprint could be found in the comments that others made.
Outsiders also came to hear the announcement. The Easter Bunny had this to say: “I understand what Santa’s doing and to be perfectly frank he’s in a different position from us in Easter Hollow. He’s facing some real time to market issues and competition with Mom & Dad, Grandpa & Grandma, and others. His competitors have real advantages in local sourcing, customer relationship management, and technology. Santa just hasn’t kept up and now it’s time for a radical change. I don’t think anything he’s doing is going to change our approach. We pride ourselves on stability of delivery and with a 98.2% market share on Easter…we’re just not facing the same issues.”
The Easter Goose has the other 1.8% of the Easter market.
Merry Christmas agile community. Enjoy your holidays, stay safe, and as always….take care. 😉
Introduction
The Kanban technique is popular within software development circles. It borrows from the world of manufacturing where the original Kanban method is used to govern and regulate the production by any one operation so that it works in tandem with the overall production process and plan. This article looks at how Kanban limits work in process inventory in software development and seeks to understand the value of doing this.
Work in Process in Manufacturing
In manufacturing Kanban is used to limit WIP inventory in manufacturing processes. But why is this done? What’s the problem with WIP inventory in manufacturing? Isn’t having enough work and supplies for the next operation in line a good thing?
The answer centers on cost. Excessive amounts of WIP inventory in manufacturing cost money. Kanban isn’t about getting faster, or delivering a better quality product…it’s about not wasting materials, machine cycles and time creating something that won’t be needed. Overproduction of WIP inventory creates these costs:
1. Spoilage – too much work in process inventory can result in wasted goods ( especially food production ) because the downstream operation doesn’t need all the WIP inventory that was produced.
2. Overproduction / over purchasing of a part – If an operation in a manufacturing plant routinely produced more widgets than were needed by the next operation using them then the purchasing department is probably acquiring more raw material for that one operation than is actually needed by the overall production schedule. This would result in the company having extra raw materials, which are often ordered in large lots for price optimization.
3. Wasted Operator Time – This cost is a bit of a paradox. Look at an operation that overproduces and it may appear in isolation that it is productive by a simple ratio of units produced/hours worked. But, in truth the operation is just wasting the operator’s time because what he/she is creating isn’t needed. The operator could be used elsewhere in the plant doing other productive work or even be sent home to help reduce labor costs ( assuming they are paid by the hour or unit produced ). The wasted operator time may actually cause overstaffing as well.
4. Wear and Tear / Unecessary Maintenance on Machinery. – overproduction means we use our machinery unnecessarily for anything over the necessary production level. The additional maintenance and wear and tear on the machinery can get expensive depending on the operation.
5. Increased Storage Costs – Excessive WIP inventory may need to be stored somewhere beyond the immediate operating space for a particular operation. This usually means stocking the excessive WIP in a warehouse. Warehouses cost money to build, operate and maintain. By limiting WIP and adjusting cycle time and throughput through a plant you can eliminate the need for a warehouse and move toward a JIT system with your suppliers.
Does Limiting WIP inventory in Software Have a Similar Corolary?
First, what is WIP inventory in software development? In a very thorough article on InfoQ WIP for software development is considered to be “tasks actively being worked on”. It’s interesting to note how Kanban flips scrum upside down. In Scrum we size the work to fit a time-boxed iteration. In Kanban we size the time to fit a work-boxed unit.
But what are the costs associated with overproduction of WIP inventory in software development? Are there any? Let’s model this from the manufacturing world first and then see if we can find other costs that may be unique to the application development space:
1. Spoilage – It’s hard to say a requirement, feature, task, or idea would ever become ‘spoiled’ in the strict definition of that word. You might be able to say that a requirement is no longer relevant or needed. So perhaps there is some cost associated with the business analyst over-soliciting enhancement requests that will never be built. But most new software development efforts have some baseline set of requirements that must be produced for the system to be coherent. So letting the Business Analyst work ahead to get those nailed down in an efficient and comprehensive way that speaks to designing a ‘whole system’ is probably worth the expense. Further, software development is not manufacturing. It’s new product development and has an element of creativity. This element of creativity requires some waste. All creative efforts do.
2. Overproduction / over purchasing – If the developers over produce on tasks, resulting in a large WIP for the QA team, does this in turn cause a business analyst to generate even more requirements? Maybe. If you’re Facebook and you’re always adding new features to your product then software development can be seen as a production line. It’s a never ending stream of work for Facebook which probably requires some regulation of workflow to balance necessary resources. But if you’re Pepsi and you have a simple capital project that will end when the funding runs out…then there is probably a finite set of requirements and you run no risk of overproducing on those requirements.
3. Wasted Operator time – There may be cost here if the business analyst, programmer, or QA professional are working on requirements of no real value or the requirement is not needed. Does this happen? Sure. But I don’t see how Kanban prevents this from occurring. Sometimes low value or worthless features are requested, everyone agrees they should be built, and it doesn’t become obvious until after completion that the feature should never have been added.
4. Wear and Tear / Unecessary Maintenance on Machinery – This cost is hard to visualize for software development. What would be the equivalent? Too much pounding on the keyboard? Too much use of the CPUs? Given that the computer would probably be used for something else if it were not being used by the developer/qa professional in association with their direct work; it seems there is a very minute wear and tear cost.
5. Increased Storage Costs – I can’t think of any storage costs that would be born with tasks that are not completed. It costs virtually nothing to save these on whatever storage device houses them. In fact the cost of storing anything in memory has been going down for decades. Further, it’s likely the storage costs are spread across many budgets as more than one system probably shares the storage space.
So, some minor cost savings may come from limiting WIP in software development, but what should be very clear to any business professional is that Kanban in software development isn’t focused on achieving the same goals it achieves in manufacturing.
Kanban in manufacturing is seeking to limit the costs associated with overproduction of WIP. Inventory costs are significant in manufacturing and need to be controlled, managed to limit their cost in the final product. Kanban is a proven technique for this.
Kanban in software is seeking to limit WIP, but not for cost reasons. The major cost in software development isn’t inventory. It’s hours worked by people. That cost comprises 90-95% of the cost for a finished software product. So does Kanban in software limit hours worked?
Continuous Flow?
Software Kanban models the production flow of tasks associated with a software development effort. Rules are established for production. As an example: the development team might set a limit of 3 done tasks as their kanban. In other words they won’t produce any more tasks until at least one of the 3 done tasks is taken by the QA team for review. This is a pull system. Downstream processes determine the production of the upstream processes.
What makes this model successful in manufacturing is something called ‘cycle time’. Cycle time is the normalized time required to produce a widget. In most manufacturing processes cycle time for any one operation is well known. This makes a pull process ideal.
In software development cycle time for any one task is variable. This means setting a work in process limit on tasks will not necessarily guarantee continuous flow. Further, in manufacturing a widget sent to a downstream operation is ‘complete’. It’s not waiting on any further refining by the upstream process or any additional widgets. In software development a task that is done isn’t necessarily testable. It may require execution of a 2, 5, or 10 tasks for a piece of work to be testable. So even though the QA team accepts additional work tasks from development, they may not be able to do anything with them.
Thinking through those points, it doesn’t appear that Kanban would limit hours worked by anyone. In fact, it may actually do the opposite and increase the cost of the software development process as upstream operations wait until the downstream process completes work. This idle time, might be seen as valuable in allowing a team of developers, business analysts, or testers to switch to another project while waiting for completion of downstream tasks on an existing project. But this then brings up the question of context switching and introduces even deeper complexities, entanglements into the production process.
Visibility of Workflow…the Real Value
So if Kanban doesn’t necessarily yield a more efficient development effort then what is the value? Is there any? The Kanban board is used to model the production flow of software development through its major person roles: business analysis, development, QA, acceptance testing, and release management. This board is visual and if kept up to date gives an interesting view for anyone hoping to manage the software development process. At a quick glance the team can easily see where things are potentially bottle-necked and begin to focus on how best to free up that bottleneck. This is the strongest value Kanban offers to software development: kaizen on the flow of tasks.
Summary
Does this article suggest Kanban is misguided in its implementation in software development? Not at all. Attempting to borrow techniques from other industries that have been successful is a useful, pragmatic approach. Modeling the flow of tasks between processes has value in just opening up questions about why something isn’t done and what’s blocking completion. However, this article does suggest that hoping to see significant, immediate cost savings in your development process using Kanban may be a false hope. The true value will be unlocked by continually focusing on how best to increase the number of requirements produced per hour by the team.
Pragilematic 