« January 2007 | Main | March 2007 »
February 27, 2007
Interesting Quote
I couldn't find this anywhere with my few Google searches, so if anyone knows where this is from, please let me know:
The bitterness of poor quality lasts longer than the sweet taste of meeting a deadline
Posted by Mishkin Berteig at 12:02 PM | |
February 22, 2007
Strategic Plan
Okay, this is only marginally related to agile, but I thought it was interesting nevertheless: How to Write a Detailed Strategic Plan. The main connection to Agile Work, is that you need to have a clear performance goal in mind towards which you are working. This may be a great way to clarify your thoughts about such a goal.
Posted by Mishkin Berteig at 11:43 AM | |
February 21, 2007
When is Scrum not Scrum?
Tobias Mayer has written a fascinating and valuable article about what it means to be doing Scrum. There are some very practical ideas (e.g. shortening Sprint or iteration length) and some more philosophical ones (e.g. the ScrumMaster role is not always necessary!) It's a great read, and I agree with everything there, except for one point...
Tobias mentions that one must insist on agile engineering practices when doing Scrum. There are two problems with this.
First, not all development environments have the tools to support the agile engineering practices. For example, one team I coached was using AbInitio; there is no ABUnit test-driven development framework. As another example, a team was doing a software upgrade project where again, there was no easy way to write automated tests (there was a hard way), nor was there any way to do continuous integration short of totally re-architecting the system. Nevertheless, doing a version of Scrum helped immensely.
Second, these engineering practices are even harder to do when the work in question is not related to software. For example, I use agile methods to run my business. I don't pair program, I don't do test-driven marketing (at least not in a way that is clearly comparable to test-driven development). These things just don't apply.
Now granted, Scrum is a software development methodology at its heart. The concept of the Product Owner, the Demo at the end of the Sprint, and a number of other things tie the language of Scrum to software product development. Any time it is taken out of that context, there is a stretch.
Also, please don't mistake this disagreement with a feeling that quality is something that can be relaxed. I have very strong feelings about technical debt and quality.
Posted by Mishkin Berteig at 09:21 PM | |
February 20, 2007
Learning Vocabularies
Last April I wrote a brief article showing the relationship between five different learning models. I've discovered two more for your edification:
The Shewhart (Deming) Cycle of Plan, Do, Check, Act
and the Six Sigma DMAIC cycle: Define, Measure, Analyze, Improve, Control
I find it so interesting that the same basic ideas have circulated (no pun intended) in so many different disciplines for so many years. Does anyone know if there is a good description of a universal / abstract cycle of which all the others could reasonably be considered instances?
Posted by Mishkin Berteig at 05:51 AM | |
February 15, 2007
Transplanting the Toyota Way
Thanks to Mark on the scrumdevelopment Yahoo! group for pointing out this great little article: The Toyota Way is Translated for a New Generation of Foreign Managers. The main thrust of the article is the difficulty that Toyota has had in getting managers outside of Japan to accept some of the core principles and practices of the Toyota Way. One interesting example:
Worse, some executives like Mr. Konishi complain of managers at Toyota factories who have not adhered to some of the company’s most basic creeds, like allowing workers to stop factory lines when they spot defects. Empowering factory workers has long been central to Toyota’s quality control.
Posted by Mishkin Berteig at 10:40 PM | |
February 12, 2007
Agile Retrospectives Google Tech Talk
This is good: agile retrospectives.
Posted by Mishkin Berteig at 06:21 PM | |
To Be or Not to Be Agile
by Paul Klipp
For a decade now, agile processes, of which the best known is probably eXtreme Programming, have been gaining wide acceptance among developers, but many customers are still in the dark. Agile sounds good, but what does it mean? This is a quick and dirty preview of what you can expect when you choose an agile process.
At it's core, an agile process is designed to address a long-standing problem with traditional development methods: scope-creep. Most traditional processes begin with a thorough description of the desired product and then code until it's done. The weakness of these approaches is that in the event of a change in the business need or a reevaluation of the plan, much work can be lost and deadlines can easily slip out of control, and costs with them. The traditional way to address this problem is with change documents. A change document basically is a way of telling the customer what it will cost to make a change to the plan after development is underway. Agile processes are designed to do away with the cost of change so that the client is free to evolve the system under construction toward the ideal end goal, even if it is a moving target.
That's a tall order and skepticism is understandable.
Here's how it works.
As the client the first thing you want to do is to verify that the project has a positive ROI. I assume that you know why you want the software, what need it will serve and what value it will provide. What you need is a cost estimate to decide whether it's worth moving forward or not. The first round of planning provides that, but keeps things very rough and flexible.
As the project manager I help customers define the top level requirements and then the developers make rough estimates of the time needed to build the core components of a release. A release in an agile process is the first planned deployable version of your product. It's the first version that provides enough value to justify using it. Here is the first major difference between agile and traditional development. Using a traditional approach, you get your software when it's all done. Using an agile approach, the team builds many working versions of the software, and you get to choose when a version offers enough value to use, so you start enjoying benefits sooner.
If, based on the rough estimates, the client decides that the ROI is positive and chooses to proceed, I begin planning the first release. A team consisting of developers, a project manager, testers, and a customer who all collaborate on every phase of the process. Developers provide estimates and solutions, the project manager makes sure that the project runs as efficiently as possible and everyone has the information they need to do their job, testers help to write acceptance tests and they run both acceptance tests and unit tests, but the customer has the most important job of all. The customer writes the user stories, acceptance tests, answers developer questions during the development process, and decides when an iteration (a working version) of the product provides enough value to deploy. To be clear, I should explain that I use the word client to refer to the company or individual who commissions the software product. I use customer to refer to the team member (who typically works for the client) who is responsible for these very specific duties described above.
The release plan begins with a system metaphor and user stories. The system metaphor is a simple analogy that describes how the system will work. For example, Lunar Logic Polska recently created a purchase request system for which the system metaphor was an online store. That metaphor served two purposes. It allowed the developers to make intelligent choices when confronted with vague details in user stories and it provided much of the vocabulary for the project. Kent Beck has deprecated the system metaphor concept in XP, but I still find it useful. When it's not appropriate, other tools can be used to create a shared vision for the team.
User stories are described in more detail in my other articles, but they are basically short statements of functionality, just a title and a sentence or two, that describes what the product does. The project manager works with the customer to create the user stories in plain language. The details are filled in as needed during development by dialogs between the developers and the customer.
Once all of the stories for a release are written (the customer can add or remove stories between any iterations), developers estimate the time required for each story. They use best case scenario estimates. By consistently using best case scenario estimates, the developers set a standard for estimating that is easy to understand and apply. If a story is too complex, developers will work with the customer to reduce it to smaller stories. For some user stories, the developers might break the function into tasks defined in development stories that are attached to the user story. I have been experimenting for a few months with Mike Cohn's idea of planning poker and using story points to reflect complexity rather than time estimates and my team has generally found this to be a better approach.
The customer then takes the stories with the estimates and prioritizes them. I like keeping the priorities simple: high, medium, and low. There might be dependencies that aren't captured yet, but that's why the customer participates in creating the iteration plan. For some projects we use the DSDM MoSCoW system for priorities (Must have, Should have, Could have, Won't have).
Using the user stories and developers' estimates, we create an release plan. We decide how many iterations to do and how long each iteration should be. An iteration is a concept that deserves more description. An iteration is an agile way to achieve two main purposes: to produce usable product fast and to keep the code simple. It also helps to adapt to change. An iteration can last from one week to three months depending on the scale of the project. I prefer to keep them to a month at most. Each iteration produces a usable product. The exciting thing about iterative development is that the customer retains the right to change direction, change teams, or pull the plug and still have value to show for their money. As I wrote in a previous article:
"The beauty of iterative development combined with continuous integration is that if we approach a piece of software with the intention of working until all features are done (traditional approach), then at no point in the project is there usable code except at the end. Whereas with iterative development, the client can pull the plug at any time and have a working product, even if not fully-featured. For example, halfway through a large, waterfall or RAD (Rapid Application Development) style project we might have had a working administrative interface but not working user interface, or no user authentication system; in other words, a fundamentally flawed and unusable product. Halfway through an agile Project (at the end of any iteration) we have a product which, though lacking some intended features, actually had all the essential components of a software tool finished, tested, and ready to deploy if desired. The customer is not married to the project and the developers can't hold the project hostage until the bitter end; If it concludes early, the investment is not a sunk cost."
Iterative development also means that there are logical places to stop, reevaluate, change stories, and change the direction of the entire project if necessary, without causing any significant disruptions to the process.
An iteration plan assigns stories to an iteration based on the resources dedicated to the task and the time limit set for the iteration in the release plan. During development, developers work through stories in order of priority, occasionally asking the customer for clarification. The first thing the developers do each day is to discuss the plan for the day and get feedback from other developers on how best to approach the day's stories. Then, each developer begins a story by first planning the work necessary to implement it, and then writing unit tests to test the desired functionality of the code they plan to write. Writing unit tests before writing code forces the developer to clearly think thorough what needs to be done and the best way to do it. It also gives him a distinct goal - write the simplest code that will pass the unit tests. As he finishes each story, he integrates the code on the integration server and runs unit tests to ensure that his update hasn't broken any other functionality. When a story is complete, the developer notes the time taken to complete the story (we use this to refine our velocity calculation) and announces to the team that the story is complete, attaching a screen shot or video that illustrates this new function. The customer is welcome to offer immediate feedback so that story functionality can be tweaked early on, while the code is still fresh in the developer's mind.
As work progresses, I track actual time against estimates and thereby arrive at the team's "velocity." Knowing the velocity of a team on a project allows me to evaluate their future capabilities rather than second-guessing the estimates as would happen in a traditional method.
Meanwhile, the tester is working with the customer to write acceptance tests. More about this component of the customer's job can be found in my articles regarding the role of the customer. The tester is responsible for leading the team of QA testers who run acceptance tests on closed stories and verify that unit tests are passing. They produce regular reports of test failures that the developers use to refactor as they progress.
At the end of the iteration, which takes place at precisely the predetermined time, the testers run unit tests and acceptance tests and when everything passes, the working product is tagged in cvs. The customer now can decide whether to deploy the product of this iteration or to wait.
The iteration planning cycle then repeats. The customer can add or reprioritize stories and then a new iteration plan emerges. It is not at all uncommon for customers to have a much clearer idea of what they want as they see a project evolve. Iterative development accounts for this fact and gets working software into users' hands as fast as possible so that course correction is not delayed.
This has been a very brief overview of an agile process, but hopefully it illustrates how by using agile techniques, companies like Lunar Logic Polska are able to fulfill for their customers the ideals enshrined in the "Customer Bill of Rights" (http://www.c2.com/cgi/Wiki?CustomerBillOfRights):
Customer Bill of Rights
* You have the right to a plan, and to know what can be accomplished, when, and at what cost.
* You have a right to get the most value for each programming week.
* You have the right to see the progress in a running system, proven to work by passing tests that you specify.
* You have a right to change your mind, to change functionality, and to change priorities without incurring exorbitant costs.
* You have a right to be informed of schedule changes in time to choose how to reduce scope to restore the original date. You can cancel at any time and be left with a useful working system that reflects your investment to date.
If you know exactly what you want, and you know your needs won't change, and you are prepared to work with a software vendor to create a comprehensive document describing every aspect of the software you want created, and you are willing to commit to not making any significant changes in plan, and you trust your vendor to deliver exactly what you expect on time, then an agile process may not be right for you. If any of these statements do not apply to your project, then nothing will mitigate your risk and improve your level of control over your software project like a well-implemented agile process.
copyright 2006 Paul Klipp
Posted by Guest at 08:37 AM | |
February 05, 2007
Iteration 6 - Cleanup!
Well. Last iteration was great! I didn't document it, because it was trivial: I had one full day coaching engagement plus a two-day public course. And then the rest of the week I did nothing!!! What a joy! Anyway, now onto iteration 6 - cleaning up from the cancelled iteration and catching up from the vacation.
My plans this week are simple:
1. Training Follow-up: lots of admistrative details to take care of.
(7 Tasks)
2. Coaching Follow-up: some marketing and coaching things to help my client.
(3 Tasks)
3. Development Work for my Client
(6 Tasks)
4. Long-overdue Financial Stuff: getting papers in order, doing spreadsheets, etc.
(4 Tasks)
5. Reduce Email Inbox Backlog by 125 messages
(2 Tasks - this is an odd one which I'll talk about more in a moment)
6. Prepare Some Technical Training Materials
(1 Task - collect already existing materials into a single piece)
Reducing my email inbox is really about 125 tasks, but most of them will be very fast. From past experience, getting rid of 125 messages should take between 4 and 8 hours of concentrated work. We'll see!
I'm committing to 23 Tasks. This should be about right, although, (again!) it might be a bit of an over-commitment. The only reason that I think I might be okay here is that I am trying to include more of the stuff that I would be doing anyway but just not reporting on my Work Queue. The admin stuff in particular!
To be clear: the past few iterations I have learned about my capacity. This time, I am trying to be more visible. Usually, I do not put _everything_ on my Work Queue and in tasks. I leave out things that are small or that I am always doing. I'm going to try to become more honest about what I am doing, not just my capacity. We'll see how it goes!
Posted by Mishkin Berteig at 12:27 PM | |
February 02, 2007
Let the Experts Make the Decisions
In many traditional organizations, developers end up making business decisions that they have no right making. Maybe they are not able to get timely feedback from a business expert. Maybe they are so 'sure' of the answer they just don't bother asking. Maybe they are so knee deep in technical details they don't realize they are making a business decision. If they make the wrong choice, this can have some pretty nasty consequences for the business in question.
As a result, agile practitioners have a strong focus on putting business decisions in the hands of business people. The business expert (product owner in Scrum lingo, customer in XP lingo):
- prioritizes features
- provides feedback on working software on a regular, frequent basis
- defines acceptance criteria for features
- remains available to work with developers and answer questions to ensure the features under development are meeting business needs.
Too much of a good thing
Sometimes, I see an agile team give the business expert too much control. I know, that sounds like heresy. Too much control in the hands of the customer? Is there such a thing? I think there is. Hear me out.
The reason agile practitioners put business decisions in the hands of business people is pretty obvious: they are the experts. They have the deepest understanding of the business needs. They are best able to understand the relevant consequences of the decision. As a result, they are in the best position to make the call.
For some decisions, though, the developers are the ones best able to understand the relevant consequences. I am not talking about most "technical" decisions. If you can easily translate the technical consequences to business consequences, it's not really a technical decision. When that's the case, explain the consequences in business terms, and let the business expert decide.
So what am I talking about?
I'm talking about decisions regarding software development process and practices. Consequences of these decisions are not clear, obvious, and easily comparable. They are subtle and complex. They require experience and expertise to understand. These decisions should not be left in the hands of a novice, and when it comes to software development, chances are your business expert is a novice.
Consider this exchange:
Bob the Developer: "Hi Jim, I wanted to ask you something. I'm working on feature x, and I've noticed that it would really help if we refactored the code we wrote when we implemented feature y. It's kinda becoming a mess."
Jim the Business Expert (looking confused): "I've heard you guys talk about refactoring before, but I'm not really sure what you mean... do you mean you'll have to go back and fix the code for feature y? I thought we were done with that one."
Bob: "Well, the feature is working fine, but we took some shortcuts in the code. It's making it hard to work in that part of the code now. It's going to be a real problem as we move forward."
Jim: "Hmm. How long will it take?"
Bob: "It'll take about half a day to refactor the existing code and add the new feature."
Jim: "Can you add the new feature without doing this refactoring?"
Bob: "Hmmm. Well, I'd rather not, but I think we could hack it in. Doing it that way would take about an hour."
Jim: "Well... we have a lot of features to work on, and marketing is expecting the first release by June. I think you should do it the quick way. I'd rather not waste a few hours on refactoring if it's not really necessary."
Whether or not to refactor as you develop a new feature is not a decision that should be posed to a business expert. It takes a fair amount of software development experience and expertise to understand the effects of refactoring vs. not refactoring. As developers, we are the experts when it comes to software development process and practices. We should recognize that, and act accordingly.
I like how James Shore puts it:
"If a technical option simply isn't appropriate, don't mention it, or mention your decision in passing as part of the cost of doing business."Letting the customer steer the project is great, but don't give them the opportunity to steer it into the ground by making inappropriate technical decisions. Stand firm when it comes to responsible development practices. Use your best judgement. Remember, you're the expert.
- Ryan Cooper, On Agile
Posted by Guest at 06:05 PM | |