I once worked for a company that prided itself of doing distributed agile. The vision was to have one team split across two different country so that work could continue around the clock. They had the development team in Chicago and a testing team in India. Work completed in Chicago at the end of the day, was tested in India overnight … or at least that was the sales pitch.
Read the rest of this entry »
Filed under: Planning, Project Management, Scrum , distributed, distributed agile, distributed scrum, distributed software development, Planning, Project Management, Scrum
Image by PSD: http://www.flickr.com/photos/psd/
Someone asked me recently what where the five top reasons why companies adopt Scrum. I had difficulty answering this question, because, without doing a reasonably rigorous survey it’s difficult to provide a comprehensive answer. I do however, have some experience with companies adopting Scrum and I could provide the top five reasons that I’ve personally witnessed.
Read the rest of this entry »
Filed under: Agile Software Development, Organisation Change, Planning, Project Management, Scrum , Agile Software Development, Organisation Change, Planning, Project Management, Scrum
Planning Poker cards make great promotional items. They are both fun and useful, and many companies freely distribute Planning Poker decks as part of their marketing efforts. But you don’t need some brand name deck to make Planning Poker fun and interesting. A creative idea, a printer and some stiff paper is all you need to make your own deck.
Custom Planning Poker Cards
Here’s a deck from a company that I was at a few weeks ago. The team is coached by
Angela Druckman, and had a common interest in wine tasting. As you can see the results are fantastic! I absolutely love these cards.
Filed under: Agile Software Development, Planning, Project Management , Agile Software Development, Estimating, Planning, Planning Poker
Is your team having difficulty forecasting when a project will be completed? Do you have a large number of un-estimated Stories in your product backlog? Are your planning meetings several days long and full of confrontation? If so, it could be that you’re forgetting to “groom” your product backlog.
Read the rest of this entry »
Filed under: Agile Software Development, Planning, Project Management
Personal Comment: I started this article about 5 months ago and it’s just been sitting in my queue. I’ve been undecided about publishing because I’m not especially fond of it. But rather than let the bits rot, I thought I’d share it in the hope that someone will get some benefit out of it. If you find this interesting or helpful please leave a comment. Thanks.
The concept of “dog fooding” your own products has been around for a long time, and has been made famous my Microsoft who are rumoured to practice “dog fooding” their products as a regular part of their culture. What is dog-fooding?
Read the rest of this entry »
Filed under: Agile Software Development, Patterns, Planning, Technology
The Enhanced (or Alternative) Release Burndown graph [1],[2] is a great tool and one of my personal favourites. It demonstrates several things very clearly. It demonstrates:
- The rate at which work is being completed by the team
- The rate at which new work is being added to the product backlog
- And, it can be used to determine a date range for completion.
Read the rest of this entry »
Filed under: Agile Software Development, Patterns, Planning, Project Management, Scrum
This first appeared on the ScrumAlliance.org website on October 30th. It is presented here in its original unedited form.
Burndown graphs are commonly used in Scrum projects to give the team an understanding of the amount of work remaining for the Sprint (or iteration). In Ken’s own words:
“As a team works together, it develop its own style of creating and maintaining the Sprint Backlog. It also demonstrates unique work patterns, some working consistently, some in bursts, some at the end of a Sprint. Some seek pressure, while others seek regularity. Across time, the backlog charts of each team develop predictable patterns. They stabilize as the team learns the technology, the business or product domain, and each other. These chart patterns are called Sprint signatures.” – ControlChaos.com [1]
Read the rest of this entry »
Filed under: Agile Software Development, Patterns, Planning, Project Management, Scrum
This last week I was at the ScrumExchange conference down in Palo Alto. It was an great conference and I especially enjoyed the sessions led by Matt Smith [2]. They were thought provoking and very entertaining … an great foil for some of the other heavy material.
Read the rest of this entry »
Filed under: Agile Software Development, Planning, Project Management, Scrum
This is the second article that I wrote for the Scrum Alliance [3]. It was orginally published on July 24 and can be found here. The article presented below is the original unedited version with all my grammar and spelling mistakes!
Read the rest of this entry »
Filed under: Agile Software Development, Patterns, Planning, Project Management, Scrum
InfoQ readers: There is an incorrect link on InfoQ. If you’re looking for the Rothman article on addressing technical debt, you can find it here. But since you’re here already, why not stay a while and enjoy the view?
This article was written for the ScrumAlliance [3] and featured on the site on 17th July, 2006. There was some significant editing before it was featured [on the ScrummAlliance.org website] so there are differences with the article presented here. The message however remains the same. You can find the original article here.
This article is the orginal unedited version, complete with bad grammar and spelling mistakes!
Read the rest of this entry »
Filed under: Agile Software Development, Estimating, Planning, Project Management, Scrum
A question that often comes up on Agile projects is; how do I determine when I can release software? For most project teams that are accustom to a defined process (Waterfall, RUP etc) it’s not immediately obvious how transition an Agile project from “Development” to “Production”.
I have put quotes around “Development” and “Production” because, within the Agile world, there is no concept of a “Development” phase nor a “Production” phase.
But regardless of Agile niceties, how do Agile projects go live?
Read the rest of this entry »
Filed under: Agile Software Development, Estimating, Planning, Project Management, Scrum
I’ve recently been coaching a team that has taken particularly well to Scrum. After a few iterations the project team quickly settled down into a regular rhythm of producing software. The ScrumMaster (Ken) dutifully recorded the teams Velocity [the number of Story Points completed per iteration], in addition to some financial metrics. This included the cost of each iteration (also known as the burn rate).
At some point the Ken decided to calculate the cost of each story point. This is a brief description of what he did and the results.
Read the rest of this entry »
Filed under: Agile Software Development, Estimating, Planning, Project Management, Scrum
Personal note: I started this article about 9 months ago. Although it’s quite a fun article, I have become increasingly critical of the use of analogies to describe software development. My feeling is that analogies lead to assumption that may, or may not, be valid. So, rather than talk about building a bridge, a house or cooking Thai food I’d rather talk about software specific problems or situations.
After some personal doubt I finally decided to complete the article because it is amusing, if not insightful. I hope you enjoy the article. In the future I’ll endeavour to keep analogies far, far away.
Mae Phim is a small Thai restaurant in Seattle [1]. I went there with my colleagues last year and we were impressed with their speed of operations. Within the space of a few short minutes, we were able to place an order and received a hot, freshly cooked meal.
Despite the short duration, it was sufficient time for us to wonder if there were any lessons here to use in Agile software development. After all, if we were able to deliver software as rapidly and with the same high quality as Mae Phim delivers food then that would surely be a good thing.
An interesting observation was that the business model for Mae Phim is common to the business model of other Thai restaurants [especially those that cater to the lunchtime crowd who present their own set of unique challenges]. This article discusses some of the characteristics of their operation and discusses the applicability (or not) to developing software.
Read the rest of this entry »
Filed under: Agile Software Development, Cultural Change, Organisation Change, Patterns, Planning, Project Management, Scrum
[Update: This is part 3 of a four part series. Here are links to part 1,
part 2, part 3 and part 4.]
In the first two articles in this series I discussed an overall road-map for introducing Agile methodologies into an enterprise [1] followed by a plan [2]. Both of these articles only considered an idealized scenario, one in which there was a logical progression and there was little (if any) objection. This is seldom the case.
There is often very strong resistance to the introduction of Agile methodologies from many quarters. This resistance may be direct, or it may be indirect. Ultimately however it is related to the organization’s or individual’s perceived threat to their position, authority or compensation (i.e. power and money).
This article discusses some of the impediments that may be faced by a transition to Agile methods.
Read the rest of this entry »
Filed under: Agile Software Development, Cultural Change, Organisation Change, Planning, Project Management, Scrum
[Update: This is part 2 of a four part series. Here are links to part 1,
part 2, part 3 and part 4.]
As Agile methodologies gain wider acceptance, they will be taken up by larger numbers of organizations. The question of how to introduce an Agile methodology into an enterprise with the least amount of risk will become more and more common. The two approaches that are typically talked about are Top-Down, where senior management take the initiative to introduce Agile, and Bottom-Up where developers and testers take the initiative to introduce Agile.
The truth of the matter is that both of these approaches have flaws. The successful approaches that I’ve witnessed have used some combination of both the Top-Down and Bottom-Up approaches. Agile software development practices can force large changes in the corporate culture, and making the change to an Agile organization is only possible if there is support from all parties involved.
Ultimately, there needs to be some coordination of both these efforts. There needs to be some planned approach to deal with concerns raised by those who do the work, in addition to those who lead the organization and make the strategy a reality.
Read the rest of this entry »
Filed under: Agile Software Development, Cultural Change, Organisation Change, Planning, Project Management, Scrum
I’ve long struggled with the concept of Story Points and how to effectively communicate this to clients. It’s never been a natural concept for me, and most explanations of Story Points are half baked. Explanations such as “Story Points are relative measure of complexity”; are quickly countered with “What about situations where something is not complicated by takes a long time to build?”
Most Agile practitioners end up trying to cover all bases by defining Story Points as some measure of both size and complexity [3].
Read the rest of this entry »
Filed under: Agile Software Development, Estimating, Planning, Project Management, Scrum
When an Agile methodology is introduced to an organization for the very first time, it’s quite common for the client to ask: What are the characteristics that indicate a project will have the highest likelihood of success? Most experienced Agile practitioners have an intuitive feeling for which projects would be successful using an agile methodology. This includes such factors as the project having a direct contribution to business value, or having a dedicated business customer. Even though this may be understood by the experienced practitioner, that does directly help the program manager with the selection process.
This article describes an “Agile Scorecard” that can be used as a first pass filter for selecting Agile projects. The intention of the Agile Scorecard is to provide a simple manner in which projects can be reasonably selected by a project team that is unfamiliar with agile methods.
Read the rest of this entry »
Filed under: Agile Software Development, Planning, Project Management, Scrum
In my last blog I descibed the Iterative Waterfall anti-pattern. I described what the problem looked liked, a variation of the problem (the Staggered Iteratvie Waterfall anti-pattern) and some of the reasons for how these anti-patterns evolve.
This week I would like to discuss how to avoid these anti-patterns and, if avoiding them is not an option, how to move a team from this model of software development to a model that is more closely alligned to Agile methodologies [such as Extreme Programming (XP) and Scrum.]
Read the rest of this entry »
Filed under: Agile Software Development, Patterns, Planning, Project Management, Scrum
Foreword: This blog entry was originally intended to be a single article. In writing it I found that I had trouble trying to communicate all the information in one sitting. As a result I’ve decided that this will be a 2 part article. The first part (presented here) discuss the Iterative Waterfall pattern and the reasons why this pattern of software development process is detrimental. In the second part I’ll discuss possible approaches to moving away from this pattern.
Update: Dave Nicolette has written a great article that provides more context, from the both organizational and team point of view. It’s well worth reading and you can find it here.
Over the last 3 years I’ve noticed a reoccuring anti-pattern amongst companies trying to implement Agile. This has happened with development teams that are particularly experienced with RUP [for reasons that I'll discuss towards the end of this article].
There are two variations of this anti-pattern, which I’ve called Iterative Waterfall and Staggered Iterative Waterfall. The Staggered Iterative Waterfall anti-pattern is simply the Iterative Waterfall anti-pattern taken to it’s extreme. Throughout this article I’ve used the term Iterative Waterfall to refer to both variations except in situations where I need to distriguish between the two.
So, what are the characteristics of these anti-patterns?
Read the rest of this entry »
Filed under: Agile Software Development, Patterns, Planning, Project Management, Scrum
Recent Comments