My first iteration using Agile Work for my business development has come to a close. Here is what I did for a “demo” and retrospective.
First Interation Ending
Reply
Tag Archives: Business
My First Challenge
Wednesday is nearly done and I’m looking at my list of tasks and cringing! I’ve only done a few out of the forty for this week. What’s going on?!
The Case for Context Switching
Recently, Dimitri Zimine wrote an excellent little story about context switching. Joel Spolsky writes in “From the ‘You Call this Agile’ Department“:
Dmitri is only looking at one side of the cost/benefit equation. He’s laid out a very convincing argument why Sarah should not interrupt her carefully planned two week iteration, but he hasn’t even mentioned arguments for the other side: the important sale that will be lost.
Okay… I’ll bite.
Agile Team Launch – a Howto Guide for Managers
Starting off on the right foot is just as important as it ever was. However, with Agile Work, this takes on a significantly different meaning than it does in other methods as the emphasis of what is “right” is also significantly different. This is a short guide on how to successfully launch a team using Agile Work.
The Product Owner Role
I’ve been researching the requirements and variations on the Product Owner Role for a client that I am assisting. Here is a small collection of links and notes.
Updated (Originally posted Nov. 18, 2005).
The Seven Core Practices of Agile Work
Agile Work consists of seven core practices. These practices form a solid starting point for any person, team or community that wishes to follow the Middle Way to Excellence.
Agile Project Engagement Roadmap
(Parts of this posting were adapted from an email written by my business partner, Dale Kiefling)
We recently had the disconcerting experience of having a client cancel our engagement because they’d felt that we weren’t being agile enough. In hindsight there were a number of reasons why this might have happened but I think the most important one was simply that we did not provide a clear overview of the engagement. This meant that the client was confused about the value of what we were doing. I myself am confused about how the situation arose. I thought we had been very clear but obviously that was not the case.
Agile Work Business Case – Pragmatic Reasons for Using Agile Work
Time to market/process cycle time is improved, possibly to reducing the time to that of a single iteration. This reduced time to market can produce an incredible competitive advantage both by increasing an organization’s ability to respond to change and by proactively instigating change that other organizations will not be able to respond to adequately.
Using Agile Work practices and focusing on Agile Work disciplines improves the chance of projects being delivered under budget. In fact, the whole notion of budget becomes meaningless when agile projects are delivering incredible value incredibly quickly. Profit-oriented organizations will see their budgets expand as their profit grows and non-profit organizations will see the value they deliver grow far beyond expectations with a constant budget.
Stakeholders, in particular end-users have ownership of the solution and are more likely to accept it. Whatever system or result Agile Work is used to create, that result will have very low levels of waste due to non-acceptance. This is also a reduction of the risk that the wrong solution or a poor solution is delivered.
Improvements in staff development and retention by providing a positive learning culture. In some industries and sectors staff turnover is a major expense or source of waste. Agile Work is interesting, exciting and satisfying. People who have experienced Agile Work actively promote it and seek it out because it creates a situation where their talents are valued and used effectively. Adopting Agile Work will attract talented team players to your organization.
Agile, the Adult Educator and Ethical Considerations
A review of Tara J. Fenwick’s “Limits of the Learning Organization: A Critical Look†(article found in Learning for life: Canadian readings in adult education
This article is a critique of learning organization literature (as presented in the works of Peters, Senge, Watkins, Marsick, Argyris, Schon and others). I chose to do a review of it because learning organization literature can and does inform the work of Agile practitioners. The writer, Tara Fenwick, offers a critique of this literature as an academic and practitioner in the field of adult education. Even though the language and tone of the article is judgmental and at times affronting to the corporate trainer audience, it is never-the-less challenging and valuable because she raises interesting ethical questions that can serve as cautions against potential trends that can distort agile practice. I will summarize her argument in the some of the areas most relevant to Agile practice.
Fenwick’s summary of the model of learning organization found in the literature, is an organization that: “creates continuous learning opportunities, promotes inquiry and dialog, encourages collaboration and team learning, establishes systems to capture and share learning, empowers people toward collective vision and connects the organization to its environment.â€
The following is a summary list of some of Fenwick’s critiques:
Who’s Interests are Served
Although the learning organization literature holds great promise for a more humanitarian and egalitarian workplace, it has the potential to distort learning “into a tool for competitive advantage†and in turn, exploit people as resources in the pursuit of profit. To explore this idea she asks a valuable question: “Who’s interests are being served by the concept of learning organization, and what relations of power does it help to secure?†She argues that learning organization literature tends to serve the interests of educators working as trainers in organizations and managers interested in their own self preservation.
How Learning is Defined
Learning, in learning organization literature seems to be defined as that which benefits the organization, all other learning falls into the dysfunctional category. This perspective negates other ways that people create meaning and learn and potentially causes a person to become “alienated from their own meaning and block flourishing of this learning into something to benefit the community.â€
Assumptions about Learners
The learning organization literature subordinates employees by seeing them as “undifferentiated learners-in-deficitâ€. Educators and managers are the architects of the learning organization while employees are busy “learning more, learning better and faster†trying to correct their knowledge deficit. In the learning organization workers become responsible for the health of the organization without the authority to determine alternative ways to reach that health. The fear of being left behind in a quickly changing market environment is used to create anxiety and fear as motivations for learning. All of these factors serve to put serious limits on the potential of people to learn in the work environment.
Diversity and Privilege Overlooked
Perspectives of race, class and gender -which research has shown affects the way people learn and collaborate- are lacking in the literature. Fenwick challenges the notion of achieving a democratically ideal situation for open dialog -that the learning organization literature calls for- when all people in the work place do not “have equal opportunity to participate, reflect, and refute one another†(for example because of the status of ones job, character, gender, class, age etc.)
Fenwick sheds a clear light on where the good philosophies of the learning organization are found wanting. The Agile community can benefit from asking some of the same ethical questions she asks in relation to our work. Her critique is a good challenge for Agile practitioners. It challenges us to:
- Continue to strive for higher levels of ethical excellence in our work
- To consider issues of power in our work
- To become conscious of how we use our own power
- To give thought to what voices are included / excluded in the creation of the learning organization
- Pay attention to how we motivate learners
- How to foster collaborative environments that are conscious of the privileging of some over others
- Think about who decides what is valuable knowledge and learning and how that affects the knowledge creation process
Reflecting on these issues will go a long way to contributing to the development of agile practice.
The full text of an old version of Fenwick’s article can be found here.
Agile Offshoring References
Many people are trying out Agile Work in software development. The current industry climate is one that has focused business stakeholders’ attentions on re-examining their core priorities. Where Agile optimizes on “Time to market”, the offshoring “over-the-wall” approach to software development seeks to optimize on raw dollar cost.
What do you do if your organization is attempting both? There are some good resources on-line about this already, however I have yet to see good case-studies with published figures. Also, much of what’s out there comes in the form of mini-articles that are no more than promotional ads for X proprietary “agile-offshore” solution. Regardless, some of the following may help avoid the worst problems of integrating two quite different approaches.
- Using an Agile Software Process with Offshore Development: by Martin Fowler
- A look at Valtech’s approachfrom within the project. This calls itself a case-study, but no metrics are provided
- The sad and understandable ruminations of Jonathan Nolen on his blog, regarding Agile offshoring and his expectations of the project. These attitudes and cocerns are quite common – this is a good poster for the kind of feeling you might find from developers.
- Vincent Massol’s presentation to Javapolis. No proofs or metrics, though some lessons learned are provided.
- A forrester research article on Agile Outsourcing. Note: this is only the abstract – the article is $350. (I should ask for a commission.
- Some practical advice on agile offshoring from a Thoughtworks fellow.
- Good points about customer proxies that are very applicable to offshoring with agile
- A very good summary of an ongoing conversation about fixed-bid contracts and Agile. It relates to the agile-offshore issue given that often projects are offshoring because of cost-sensitivity, and are thus fixed-bid.
- A look at criteria for choosing offshore partners based on Agile business readiness.
- Article by Scott Ambler on agile outsourcing.
Harvard Business Review Article
I highly recommend this article on Collaboration Rules. Great stuff in there about developing teams, developing organizations and how important communication and trust are to doing so. The article draws examples from and compares the open-source development and maintenance of the Linux kernal and the operation of the Toyota Production System.
Just-In-Time Value Delivery and Waste Elimination
Lean Manufacturing
If I am manufacturing computers, and I receive a large batch of CPU’s… say… Intel Pentium IIIs, I put them in inventory. There is a recurring montetary cost associated with keeping this inventory. There is, however, also a hidden cost. If I use up half my inventory to build computers, and then I inventory those computers, and I ship half of those computers, I now have 3/4 of my initial chips waiting around, earning me no money at all.
Then, Intel ships the new Pentium 4. What happens now? Well, I basically have to throw out my Pentium 3 stock (either by making low-cost, reduced-margin computers just to get rid of them, or by trying to sell the chips wholesale at cut rates). I also have to either slash prices on my remaining stock of computers, or re-fit them with the new processors. All of this is very expensive, and may eliminate most or all of the profits I was expecting to make on the original purchase. It is a scenario that is rife with waste.
Most manufacturing industry players have figured this out, and moved to a Just-In-Time model of production. Toyota pioneered much of this in the 1970s, and now inventory is seen as a liability, rather than an asset. This waste-free approach is a centrepiece of the Lean manufacturing revolution
Waste and Inventory in Software Development
Unfortunately, there is a parallel in computer software creation that has been rather poorly understood by businesses that need custom software development. Waste can be considered as anything that is unfinished, and/or unused. In software development terms, this can be applied to documents that will never be read or that might be unnecessary, and other such things. It is also true of unfinished software.
Traditional Software Development Example
Let us suppose that we ask someone to develop a piece of software with thirty features. Let us further suppose that this software will take about twelve months to produce. Let’s further suppose that ten of these are business-critical features, and that all of the features’ definitions are highly market-driven.
So a traditional software project starts to develop them. First there is a requirements analysis phase, then a design phase. Throughout there are lots of approval stages, sign-offs, etc. Then some team codes up the software starting somewhere around month five. Coding proceeds for about three months, after which the software goes through a testing process in month nine. In theory, at the end of this testing process (month twelve), we are supposed to receive the software for use, and we should be able to receive the value it was supposed to offer. However, defects are found in testing, requiring some re-work. The software is delayed by a further three months, and we finally receive it. By the time we receive it, our competetors have defined new features, and we have to submit new feature requests, whose results will not be seen for several months.
So for the entire development process, we received no business value, and continued to pay. Fifteen months from first investment until we started to achieve results that could mean revenue from the system. At this point, the software is partially obsolete. This is quite similar to the manufacturing scenario above.
Lean and Agile Software Development
Agile and Lean software development practices change this process by delivering business value a little-bit at a time. In an Agile software project, the business specifies what the most important features are (in our case the ten business-critical ones). The team then begins working in small time-boxes – say, two to four weeks. In each time-box, the team works on a small but well-defined list of features taken from the top of the prioritized feature list that we specified. At the end of the time-box, those features that were worked on are delivered to a degree of quality that each of the delivered features would be suitable for use by the customer. The whole might not be ready, but any features worked-on would be complete and production-ready.
If the team can average about three features per month (about what they pulled off in the above example), then by month four, the team could deliver a piece of software that has all ten business-critical features ready for use. The whole might not be ready, but the customers could determine whether those ten were worth taking the software in its current state, and packaging it up and deploying it. Quite simply, the software may not be “done”, but it’s “done enough”. Then the team can continue to roll-out less valueable features from the prioritized list.
Market and customer needs volatility
This becomes even more important when we consider the competition’s changes. In the traditional example above, after fifteen months, additional features were required. These may have been discovered in month six. Traditionally, these could only be considered in month sixteen. In Agile and Lean software development, however, work on these changes could be started in month seven or sooner. So the business received value early, or “just-in-time”, and they could get high-value changes “just-in-time”.
Quality
Because testing is built-in to the process, the customer is able to validate the product at the end of every time-box, so there are no large batches of re-work. The only time large batches of rework are necessary are when large changes to the basic requirements are requested. And then, Agile does not resist the customer’s desire to change, but recognizes it as an essential part of software delivery, and adapts to the changing consditions. As a result, the Agile and Lean methods are optimized to produce quality product in small increments, so quality doesn’t suffer from customers or markets changing their minds.
Summary
Agile and Lean principles are very powerful, and allow for business value to be delivered sooner to end-customers. This allows for better quality and risk management. It also allows strategic and tactical decision-making by executives to be undertaken when such decisions are most needed – not six months too late.
Firms that embrace Lean and Agile development principles are beginning to see the competetive differentiation that Toyota saw vis-a-vis the rest of the automotive industry throughout the 70′s and 80′s. It is only in the last two decades that, after adopting Lean practices, Toyota’s competitors have begun to close the gap. Agile software shops are beginning to achieve these same competetive gains. Those who don’t adapt to just-in-time value delivery – who don’t eliminate waste in their processes – will feel the results as their competitors take products and services to market far faster, and with more responsiveness to their customers.
“If you’re not on the steam-roller, you’re part of the asphalt.” – Lighthouse Design, circa 1996.
Just In Case You Haven’t Seen It Yet
There is a fantastic article about software productivity: http://www.joelonsoftware.com/articles/HighNotes.html. I love Joel’s writing style, and this article in particular has important lessons for us all, regardless of our profession: find what you can be the best at, and do that. Interestingly enough this is part of the message of the book Good to Great but applied to a whole corporation. It also applies in the context of self-organizing teams: each individual should be able to find/learn in what way they can best contribute and do that more than they do other stuff.
A Simple Rule of Thumb
Make your product/service development lifecycle shorter than your horizon of predictability. For example, if you can’t predict your competitive environment or your own capabilities outside of 4 months, then any new product/service should be initially launched at most 4 months from the time it is conceived. Once initial launch has occured, it is possible to examine the environment and make adjustments for an additional launch. One might call this experimental marketing. Ideas that just can’t be accomplished inside of one’s horizon of predictability should be considered very risky. In order to reduce this risk, these larger projects can either be broken up into smaller pieces, or efforts can be made to extend the horizon of predictability out further (this second task is extremely difficult).
Book Review – “The Tipping Point”
Overview
The Tipping Point: How Little Things Can Make a Big Difference is a book that is about the way ideas, things and behaviors go from obscurity to ubiquity in a very short period. The basic model is that of an epidemic in which three types of factors contribute to quick dissemination: 1) the network of people involved including “connectors”, “mavens” or respected experts, and “salesmen”, 2) the ability of that which is spreading to stick around, the “stickiness factor”, and 3) the importance of small physical, mental and social factors, in creating a conducive environment. The Author, Malcolm Gladwell, includes some excerpts on his web site.
Contents:
- Introduction
- One: The Three Rules of Epidemics
- Two: The Law of the Few: Connectors, Mavens, and Salesmen
- Three: The Stickiness Factor: Sesame Street, Blue’s Clues, and the Educational Virus
- Four: The Power of Context (Part One): Bernie Goetz and the Rise and Fall of New York City Crime
- Five: The Power of Context (Part Two): The Magic Number One Hundred and Fifty
- Six: Case Study: Rumors, Sneakers, and the Power of Translation
- Seven: Case Study: Suicide, Smoking, and the Search for the Unsticky Cigarette
- Eight: Conclusion: Focus, Test, and Believe
- Afterword: Tipping Point Lessons from the Real World
- Endnotes
- Acknowledgements
- Index
Assessment
This is a fascinating book, well written. Some of the anecdotes and “case studies” are mind-blowing. However, there is a bit of weakness in parts. In particular, the Afterword and the sections on The Power of Context are weakly put together – ideas do not flow well, or are too stream-of-consciousness. As well, the weight of evidence, while strong, is not totally convincing. That said, there are a couple of really fabulous stories.
One story that stands out is the study related to the “Good Samaritan”. In brief, researchers set up an experiment to test what factors influenced a person’s behavior when presented with someone obviously in need of help. At a seminary, the researchers had students prepare and deliver a brief talk on some topic. One of the topics given randomly to some of the students was the story of the Good Samaritan. The students were to take a short amount of time to prepare their talk and then immediately go to another building to deliver it. Planted by the researchers along the path to the second building was an actor made up to appear in a great deal of physical distress. As each student was sent out the door, the researchers would breifly comment either that the student was running a little early, or that they were late and needed to hurry to deliver their talk. The results were astounding: of those students who were told that they were late 90% ignored the person in distress regardless of the topic of their presentation, while 63% those with a few minutes to spare stopped to help (pages 163-165).
Relevance
There are several ways in which this book is relevent to those of us practicing Agile Work and related methods. Most obviously, the ideas in The Tipping Point suggest some lines of action we can take to promote Agile: finding the connectors, mavens and salespeople, working to make Agile sticky, and making the environment hospitible to the spread of Agile. This applies both inside organizations and in the world at large.
In my own opinion, the drafters of the Agile Software Manifesto, either by design or otherwise, came up with an incredibly sticky term: Agile.
Finally, when coaching a team to adopt agile practices, it may be most important to focus on the Power of Context. Small suggestions, small physical changes, body language, all can have a large influence on the success or failure of an agile adoption. If a coach (Scrummaster/Team Lead/etc.) can find the connectors, mavens and salespeople in the sphere of influence of the team, and convince those people of the efficacy of Agile, then convincing the team will become that much easier.