So how would I distill all of that into a single statement to communicate to C-level executives? Tom Gilb get's an honorable mention for his "The Ten Most Powerful Principles for Quality in [Software and] Software Organizations", which he summarizes as a single principle saying:

"Motivate people
towards real results
by giving them numeric feedback frequently
and the ability to change anything for success."

For me, the gist of all the above is that most corporate planning, estimation and management "systems" for software are badly broken because they utterly fail to acknowledge the inherent uncertainty and variation that cannot be removed by "up front" attempts at perfectly stable project plans and/or product requirements (see my article on "The Unchangeable Rules of Software Change"):

 

• The solution is not going to come about by striving ever harder for perfectly stable plans and requirements earlier in the project!
• The only successful way to manage that is through effective and continuous management of risk and change!
• And the most effective means of doing that is through the use of iterative and incremental techniques that put people first in order to give frequent feedback and reflection on real-results throughout the course of the project (while still leveraging the existing body of knowledge to serve those people so they can best serve the business).

Read more here: http://bradapp.blogspot.com/2008/01/what-do-you-wish-your-ceo-knew-about_10.html

I also enjoyed reading the excerpts from Steve McConnell: A. Critical Insights for C-level Executives and B. "The 10 Most Powerful ideas in Software Engineering. Brad was nice enough to include the link to download these two great resources - very cool! See his post for all information and complete context.

It's slowly dawning on me
In a recent exchange on Agile Project Management, it has finally dawned on me that when the agile software development advocates speak of project management they are not actually speaking of project management. They are speaking of managing software development. The production of code that is delivered to the customer. This code is "Part" of the project, but it in itself is not "the" project.

    Of course they firmly hold they are doing project management. And of course they are managing the production of software, as selected by the customer, in an iterative and incremental manner. But are they "managing the project" in the context found in the project management paradigm? Are they performing the processes that a project manager would perform if there was a named person performing that job description? Hard to say, since the conversation never seems to get to that point. And in the end it seems the project management processes are not the basis of the concept of "agile project management." Which of course redefines the whole concept of project management.

 

Read more here: http://herdingcats.typepad.com/my_weblog/2007/07/its-slowly-dawn.html

 

 

Is Agile Software Development the Same as Agile Project Management?
I had an epiphany today in the conversation on Agile Project Management. Agile Project Management is not about Project Management, it's about Agile Software development. Now software development an be part of a project. There are times, when the development of software "is" the project. But the development is software is not always about the project. The project may have many other aspects other than the software...

 

... The question is "when is the project just about developing software?" There are such projects. I've done a few. Operating systems, compilers. But beyond that the software always had some humans or another machine connected to it in some way. A radar system, an order processes system, a boiler, a missile. These "systems" were more than the software. The software was an important part, but it was just that a part.

    All of this is important to make the point that agile software development is not the same as agile project management. Software is a component, a subsystem of the system. The project is to develop the system. The engineering aspects of the system are just one part of the project. I posted some time ago a matrix of the Knowledge Areas and Processes Groups of the practice of Project Management. This is one of many pictures of these processes, but a good starting point...

 

Read more here: http://herdingcats.typepad.com/my_weblog/2007/07/is-agile-softwa.html

• Agility is not the point by Jason Yip
• “Am I Agile or Not?” from TestEarly.com
• How Agile Is Your Development Process? from Agile Project Planning
• Agile Alliance is getting a shake-up by Robert Fischer
• RigorousAgile and AgileImposition by Martin Fowler
• Agile software development from wikipedia
• Brian Marick wants to stir things up by Simon Baker
• A Simple Look of Lean and Agile and Is something missing in the Agile Manifesto? from Skip Angel
• Agile Insights: A "Post-Agilism" FAQ and Agile variations and Agile Insights: When is Scrum not Scrum? from Raven's Brain
• Do not let them label you “not agile” from One Yoxel

If I recall correctly, the Agile Manifesto states that individuals and interactions are more important than process or tools. I believe this is true. Sure, process and tools are important, but not as important as the people you have on your project and how well they work together to deliver software to your customers. I will take your team and trade it for any process and bet that I will deliver more value than you. A process is good, but a team is essential to building software.

That is why Scrum works. Scrum is all about the team, the whole team and nothing but the team. I like to refer to Scrum as Team-Driven Development. There are many good development, test, build and product management practices including some mentioned above, and they can all be used with Scrum because Scrum is a framework for the team.  Scrum recognizes that software developers do not deliver software in isolation - it requires a whole team including analysts or product managers, architects, developers, DBAs, quality engineers, build engineers, operations, support, and others involved in a whole-system, end-to-end, delivery cycle of a software solution frequently involving multiple iterations of reviewing working software to get it right.

Read more here: http://trailridgeconsulting.com/blog/?p=91

Some great thoughts and interesting insights. check it out if you are looking to move agile or implementing Scum in your organization.

JK has written a post-agilism faq which explains well all the things those of us moving past Agile have been talking about over the last couple of years. Post-agilism to me is the more general description for what I did in founding the pliantalliance.org. I moved past Agile and started to think about what was good about it and what wasn’t. I started encouraging others to do the same. It turns out that I wasn’t the only one doing this and Jonathan came along and coined the term ‘post-agilism’ to describe what we all were doing.

To quote Jonathan:

There is no manifesto. This is not an organized group - it is a phenomenon of people around the world who have some sort of Agile experience, and have independently moved on.

Read more of this post here: http://pliantalliance.org/?p=81

Read more on the post-agilism faq: http://www.kohl.ca/blog/archives/000184.html 

Several years ago, we started our quest towards a better way to develop software. In the process I discovered Extreme Programming or better known as XP. Though I liked many of the concepts that I was learning about, I definitely had my reservations on parts of it. However, the largest reservation I had was that it seemed that the founders and proponents of XP were requiring that this methodology was an "all or nothing" type of approach. If you didn't incorporate all of XP, you really would not benefit from the results that others have had with XP. In fact, some would say that you might actually experience worse results than Waterfall with a partial implementation.

This worried me greatly because I knew that past attempts of trying to implement an entire methodology had failed. Why? Too much to take on too fast. What I found interesting is at least for XP they were taking a Waterfall approach to adopting Agile. Instead, why not take an incremental and evolutionary approach to the adoption? Start with the highest priority items, incorporate them, get feedback on their adoption, and made improvements as needed. Continue this process at a pace that your organization can handle. Ultimately deciding how much agile is enough for your organization at any point of time.

 

Read more here: http://leanagile.blogspot.com/2007/02/agile-approach-to-adopting-agile.html

At the previous Agile Practitioners Forum, Colin MacAndrew asked the group "Does the Agile Manifesto need refactoring?" and it was encouraging to see quite a few people leap to its defence. Now, Colin simply asked a question about whether it could be improved, he didn't state that it needed to be re-written. And yet the defence of the Manifesto was so vehement it took me a little by surprise. There's a spark for an interesting debate here. I think it's one worth pursuing in a future meeting.

I hope that everyone agrees that the Agile Manifesto is an important guiding text. However, it should not be sacrosanct. Some months ago I bought a new mountain bike. Before I left the shop the assistant reminded me to bring the bike back in 6 weeks for a free service - to "tighten some of the nuts and bolts that may have worked loose during its initial use and to check everything remains in working order", he said. Now, maybe the Manifesto is still right on the mark, but unless we take the time to review its statements and principles (through debate) given what we've learned about agility in the 6 years since its inception, we won't know if there are a few "nuts and bolts that need tightening".

Brian Marick recently posted:

Six Years Later: What the Agile Manifesto Left Out.

The Agile Manifesto has worked rather well at changing the way software is built, but the Agile movement is now suffering from some backsliding and some backlash. I believe that's partly because the Manifesto is almost entirely focused outward: it talks, to the business, about how the development team will interact with it. What it does not talk about is how the team must interact with itself and with the code. In the early days, that didn't matter so much; the right interactions tended to happen anyway. But now it matters.

• Read more of Baker's post here: http://www.think-box.co.uk/blog/2007/04/does-agile-manifesto-need-refactoring.html
• Read more of Marick's post here: http://www.exampler.com/blog/2007/04/26/xp-day-toronto/
• Agile Manifesto: http://www.agilemanifesto.org/

The main question seems to be if the Agile manifesto should be evolving as we learn more about how to be more agile. This seems like the right path to me, but I can see how any updates would create heated debates and wonder if the growing agile community could agree on any one version of the text, let alone a few updates. It's certainly an interesting debate and I look forward to reading more thoughts on the subject. Check out the posts above and visit the referenced Agile Practitioners Forum for more great insights, opinions and other agile info.

**updated URLs**

In teaching Scrum during the past year, and working with organizations in a consulting/training capacity I have found more and more that some of the principles as outlined in the two Scrum books are out-dated and unhelpful. I teach what I know works and what I see as being appropriate; there are slight differences in each context of course, but there are certain practices I have found to be effective, all of which differ from standard Scrum practices; some would be considered radically different, which leads to the difficult question, the title of this essay: when is Scrum not Scrum?

I've been leading a team of 5 devs, 1 tester, 2 designers, and 1 customer for the past month or so. During that time, I've learned a lot from watching this team grow, in their relationships to each other, and in their ability to work together as a team.

What has struck me about this is that all of this happens best if I keep my nose out of it. And this is the hardest part for me.

My Struggle

I'm an experienced agile coach and team leader as well as a long-time developer. While this would seem to be an advantage, the problem with having all of this experience is that I have all the answers that the team needs -- if you don't believe me, just ask me :) All kidding aside, this is a big part of the problem. I really do have answers for most of their problems, be they technical, teambuilding, or whatever. But to help them grow together as a team, it is really important that I keep my answers to myself.

The idea is that the team must learn to recognize the issues that they have, understand what the effects of the issues are to the team as a whole, and figure out how to solve them on their own. If I  do this for them, then I remove a tremendous opportunity for growth from them.

Read more here: http://agileprogrammer.com/oneagilecoder/archive/2007/02/11/22180.aspx

It's some great info on the challenges a PM faces when transitioning from traditional project Management to the world of agile. It's hard letting go of certain decisions, ones you've always managed in the past, and managing a self-managed team is probably one of the more diffucult transitions for a PM. Thanks to Brian for sharing his real world experience!

• "...a manager role would be like a 'ScrumMaster on steriods'- a person whose job it is to remove all escalated impediments for the team, take care of external stuff to the team, lead the team by challenging it, and assists direct reports with individual development and other HR-related challenges."
• Management responsibilities are (1) provide strategic vision, business strategy, and resources, (2) remove impediments surfaced by Scrum teams that the teams cannot remove themselves, (3) ensure growth and career path of employees, and (4) challenge teams to move beyond mediocrity. The list of impediments generated by the Scrum teams is transparent to management. and it is their responsibility to assure they are removed in order to improve organizational performance.

Some interesting information on Scrum and Management- Read more here: http://jeffsutherland.com/scrum/2007/02/managers-role-in-scrum.html

In 1994, The Standish Group published a study called the CHAOS Report. This study was conducted to focus on what causes projects to not be "successful". Success being defined as on-time and on-budget. I have seen this report used by many Agile practitioners as a basis on why traditional waterfall develop projects do not work. Now that I have been using Agile practices for some time, I thought I would go back and review the report first-hand to get some insights. I found the Introduction interesting, here is what it said:

In 1986, Alfred Spector, president of Transarc Corporation, co-authored a paper comparing bridge building to software development. The premise: Bridges are normally built on-time, on-budget, and do not fall down. On the other hand, software never comes in on-time or on-budget. In addition, it always breaks down. (Nevertheless, bridge building did not always have such a stellar record. Many bridge building projects overshot their estimates, time frames, and some even fell down.)

 

One of the biggest reasons bridges come in on-time, on-budget and do not fall down is because of the extreme detail of design. The design is frozen and the contractor has little flexibility in changing the specifications. However, in today's fast moving business environment, a frozen design does not accommodate changes in the business practices. Therefore a more flexible model must be used. This could be and has been used as a rationale for development failure.

 

But there is another difference between software failures and bridge failures, beside 3,000 years of experience. When a bridge falls down, it is investigated and a report is written on the cause of the failure. This is not so in the computer industry where failures are covered up, ignored, and/or rationalized. As a result, we keep making the same mistakes over and over again.

I find it interesting that in my many years of doing software projects, that there are always project stakeholders who view projects this way and compare these kinds of projects to either building bridges or houses. However, for the reasons mentioned above, this assumes that once completed the software will last forever (or at least a very long time). This kind of thinking doesn't handle change well. It assumes that you have a control over the future and can predict change. It assumes by restricting change you will have success. So, was that true?...

Read more here: http://leanagile.blogspot.com/2007/02/re-thinking-what-makes-project.html

• The Anatomy of a Manifesto: http://leanagile.blogspot.com/2007/02/anatomy-of-manifesto.html
• An Agile Approach to adopting Agile: http://leanagile.blogspot.com/2007/02/agile-approach-to-adopting-agile.html
• Transparency is the key: http://leanagile.blogspot.com/2007/03/transparency-is-key.html

Emotional Intelligence has been proven by researchers to provide significant benefits to organisations, and high levels of emotional intelligence within the individual is a key differentiator for professional advancement and success with organisations. Organisational benefits include:

• Improved leadership
• More effective handling & resolution of disputes
• More effective development of team working
• Improved negotiations
• More cost-effective decision making
• Better quality problem-solving & decision-making

The Scrum team is an organisation (albeit a small one) and all Scrum teams would improve their capacity if they could recognise the benefits above. Within traditional software development projects we do not necessarily feel that we need to fully interact and gel as a team. The strategists and business analysts initiate and pass onto developers and testers, then to support and maintenance (at the helicopter level).

All these roles do not necessarily need to interact on a day-to-day basis. Within traditional projects the roles are not necessarily integrated as a team working in the same room, so the emotional intelligence capabilities are not a NECESSITY, rather they are a 'nice to have'.

The post discusses how emotional intelligence contains seven components that are beneficial in the Scrum world:

• Self Awareness
• Emotional Resilience
• Motivation
• Interpersonal Sensitivity
• Influence
• Intuitiveness
• Conscientiousness

Read more here: http://businessagile.blogspot.com/2005/02/emotional-intelligence-key-element-of.html
Good stuff! Be sure to read the complete post for all specifics and details in the post. Great information on EI's benefits to Scrum!

An agile coach that I have worked with in the past, Mike Vizdos, has teamed up with an artist to create a web site about agile with a weekly comic strip. This site, Implementing Scrum, has a few comics already there. Each comic examines an aspect of Scrum and Mike provides some interesting commentary related to the comic. Take a look, bookmark it, and check back regularly!

Breaking the Iron Triangle: Project Manager v Scrum Master
As a PM my general approach to initiating projects has been to build a Project Initiation Document (PID – Prince). A PID details the project objectives, initial scope, organisational structure, roles & responsibilities, deliverables, project processes (lines of communications, risk management, issue management, change control), plans, costs and timelines.

And starting an agile project I would still identify most of the above and ensure it is clearly communicated to all stakeholders.

But… I have learnt that adopting a scrum approach changes two fundamental things for a project manager:
· The Iron Triangle
· The Role of Project Manager

The iron triangle of cost, time and scope (or quality) is typically the responsibility of the project manager to manage. Hopefully tolerance levels have been set for each element of the triangle, and if the tolerance level is about to be breached or is broken, the project manager escalates their issues to the project board or steering group.

Previously on traditional projects I owned and was responsible for this triangle and reported to the project board if any risks or issues were likely to break the tolerance levels.

In a traditional project a deliverable-focused approach to planning is used (Prince = configuration plan), whereby all the intermediate work products and “pieces” of the solution are identified and a plan drawn up to show the route to delivery usually utilising a gantt chart or network diagram. From which timelines, resources, and costs can be identified and critical path analysis and risk management conducted.

Now scrum doesn’t throw this all away… rather we open out the Iron Triangle and share responsibility across the team, and recognise that no matter how well we plan the project, things will change, and problems will occur.

 

Read more here: http://businessagile.blogspot.com/2005/02/breaking-iron-triangle-project-manager.html

 I have a post titled Excellent Resources on SCRUM: Great info and video clips from it's co-founder Ken Schwaber which contains links to just about anything Scrum related via the Scrum For Team Systems website. Since then I've been discussing the various roles in Scrum with colleagues - Product Owner, The Team and ScrumMaster - to try to determine where the various roles map to more traditional project management. This led to more researching and below is the information I compiled from the Scrum For Team Systems website's Scrum FAQ's page, and there are additional Scrum/Agile links and resources at the bottom:

Does Scrum need a Project Manager?
The Scrum Master is the "Agile" Project Manager, but unlike the traditional Project Management role they aren't solely accountable for the success or failure of the project, only that the Scrum process is used properly during the project.
 
What are the Scrum Roles?
There are only 3 Scrum Roles:
The Product Owner - who represents all customers and manages the Product Backlog. This is the person who is always able to present to the team what the highest priority pieces of work to work on next are.
    
The Team - there maybe many teams who work on a Scrum project, but each team should optimally be 7-9 people; they form cross functional teams that manage themselves. It's totally up to them, within the guidelines, standards and conventions of
     the organization to figure out the work necessary to turn the Product Backlog that the customer wants turned into an increment and then to do the work to turn the Product Backlog into the increment of potentially shippable product functionality.
 
The Scrum Master - this role used to be called the Project Manager, but the Scrum Master doesn't have authority over the
Product Owner, over The Team or over anyone, they are simply responsible for making sure that the Scrum process is used as it's described; they are like a process manager - to the extent that the Product Owner, to the extent that The Team don't know how to fulfill their roles within the process - the Scrum Master is responsible for teaching them how. Different analogies for a Scrum Master are a sheep dog with a flock of sheep or a parent with a child that's growing from relative immaturity to a mature state.
Who tells the Team what to do?
The Team tells itself what to do
 
What does a Scrum Team look like?
A Scrum team looks like a group of people working together as a community. They look like people working together on a problem. If you look at a well functioning sports team - that is what a Scrum team looks like.
 
What does a Scrum Master do?
The Scrum Master is responsible for the Scrum process, for teaching the Product Owner and for teaching the team how to fulfill
their roles within the Scrum process. They are also responsible for the changes within the organization, to help the organization optimize its ability to realize the benefits of Scrum, both in terms of productivity, in terms of quality and in terms of early realization of benefit. So to the extent that an organization is dysfunctional to building software quickly with quality the  Scrum Master is responsible for going out and working with the organization to make these changes happen. So they are a change agent.
 
What does a Scrum Master do on a normal day?
A Scrum Master does not have a normal day. As a minimum the Scrum Master attends the Daily Scrum;  to listen, to hear what is going on, to see if the Team is self managing, to see if The Team is happy, to see if the Team is productive, to see The Team is creative, to see if The Team is well on target toward meeting what they have committed to for that Sprint and if not to have The Team work with the  Product Owner to add more work to the Sprint or to remove work from the Sprint so that they can meet their commitments.
   
Aside from that the Scrum Master is responsible for causing changes to happen within the Product Owner and the Team so that they optimally fulfill their responsibilities and roles. That is if the team doesn't know how to manage itself to teach them and help them  understand how to, if the Product Owner doesn't know how to manage the Product Backlog to maximize the value of each increment, to teach the product owner how to. If the organization doesn't know how to have one Product Owner to represent the entire group of stakeholders who are prioritizing the Product Backlog for the team, to help them to figure out how to do so.
    
Above and beyond that, the Scrum Master is responsible for keeping any that would impede the progress of the team and the progress of the Product Owner out of the way, and this means helping the organization change so that they can take advantage of the benefits of Scrum. So this change process often fulfils much of the Scrum Master's day.

--------------------------------------------------------------------------------
 
SCRUM ROLES
 
Product Owner: http://scrumforteamsystem.com/ProcessGuidance/Roles/ProductOwner.html
The 'Product Owner' is responsible for the ROI of the project. So this is the person who is investing or representing everyone's interest in the project and is responsible for the project delivering a value greater than the money that's been sunk into it.

The Product Owner is usually the client employee who commissions the project and owns the deliverable in terms of responsibility post implementation. In terms of project responsibilities, the Product Owner's role is to gain a high level understanding and priorities the functional, non-functional and creative requirements for the project. The Product Owner is responsible for ensuring that the functionality that is prioritized, developed and implemented meets the needs of the business and derives business benefits particularly in terms of return on investment.

Role Summary:
Defines the features of the product, decides on release date and content
Aggregates input from users, stakeholders and other interested parties to form a single view of the prioritized requirements for the system.
Is responsible for the profitability of the product (ROI)
Prioritizes features according to market value
Can change features and priority every 30 days
Accepts or rejects work results
 
Team Members: http://scrumforteamsystem.com/ProcessGuidance/Roles/TeamMembers.html
The second role in the Scrum team is the 'Project Team' itself. This is a cross-functional group of people with all the different skills that are needed to turn requirements into something that is an increment of potentially shippable functionality. So it often consists of an analyst, designer, QA person, a coder, a documentation person, all the skills that are needed to turn the requirements into something that is done. This is the team that actually commits to the Product Owner what they'll do every iteration and then does it. At the end of the iteration they show it to the Product Owner and then the Product Owner can decide what to do next.

There are often centres of excellence in software engineering organizations that group people of unique highly specialized skills, like usability engineering, database experts, security experts and systems architects. When these people's skills are needed they should become part of the team. That is they're not outside experts who simply give advice but they become part of the team for those iterations when they're needed to build architecture, to build infrastructure or to work on the database. They are either doing the work or mentoring, monitoring and guiding the people on the team who are doing the work. The key differentiator here is that they are no longer a chicken. We get them in at the start of an iteration and they commit along with the team to get something done by the end of that iteration. So for a short time they become a pig.

Role Summary:
Cross-functional
Seven plus or minus two members
Selects the iteration goal and specifies work results
Has the right to do everything within the boundaries of the project guidelines to reach the iteration goal
Organizes itself and its work
Demos work results to the Product Owner and stakeholders
 
ScrumMaster: http://scrumforteamsystem.com/ProcessGuidance/Roles/ScrumMaster.html
The ScrumMaster is the 3rd role, this used to be the project manager, now it's the person who's responsible for ensuring that the process is used as intended. There are different ways of thinking of the ScrumMaster role. One might be as a parent, because when you get a Scrum team together, at first they don't know how to self manage, they don't know how to work cross-functionally, they don't know how to work with a Product Owner, or how to work within timeboxes. So just like a parent, the ScrumMaster is responsible for teaching them how to do this until they know how, moving them from a relatively immature childlike state, to a mature self-functioning team. Similarly a ScrumMaster is like a coach, responsible for cheering them on, for being their leader, being their guide. The ScrumMaster is also like a referee ensuring that they follow the rules.

The ScrumMaster above and beyond anything has to enforce the rules. Many of the processes that are used in organizations create impediments to the Scrum team's progress. It is often easier to simply give in and accept that the organizational processes can't be changed and compromise the efficiency of Scrum and the team's output. So it is vital in order to keep the high productivity of Scrum that the rules are followed precisely and kept running regardless. By doing that, everything in the organization that is dysfunctional and gets in the way of building software regularly becomes obvious. It is the job of the ScrumMaster to remove any impediment, within or external to the team that prevents them reaching their goal of building the software they commit to at the beginning of each Sprint.

A ScrumMaster is a Leader and Facilitator and is responsible for:

Improving the lives and productivity of the development team by facilitating creativity and empowerment and any other way possible.
Enabling close cooperation across all roles and functions and removing barriers
Shielding the team from external interferences and removing "Impediments"
Ensuring that the process is followed
Inviting appropriate people to the daily scrum, iteration review and planning meetings
Removing the barriers between development and the customer so that the customer directly drives the functionality developed
Teaching the customer how to maximize ROI and meet their objectives through Scrum
Improving the engineering practices and tools so each increment of functionality is potentially shippable.

 Additional Scrum & Agile Links:

• Scrum Log Jeff Sutherland Scrum is an Agile Software Development Process that Certified ScrumMaster Trainer Jeff Sutherland invented at Easel Corporation in 1993.
• Scrum Alliance
• Scrum for Team System community site: www.scrumforteamsystem.com
• Scrum DevelopmentNews Group: http://groups.yahoo.com
• Control Chaos: www.controlchaos.com
• ScrumMaster: www.scrum-master.com
• Agile Alliance The Agile Alliance is a non-profit organization that supports individuals and organizations who use agile approaches to develop software.
• Manifesto for Agile Software Development
• Agile Software Development
• AGILE IN ACTION Collaboration, Innovation, Adaptation
• C2's Wiki on Agile Processes
• Agile Project Leadership Network
• Xprogramming.com An Agile Software Development Resource
• Agile Project Planning Thoughts on agile project planning and software development by Dave Churchville
• Agile Advice Thoughts and experiences for practitioners following the Middle Way to Excellence.
• Jason Yip's web log Jason Yip's web log about XP, Agile, Java, software development and other things
• Kevin rutherford on Agile Development This blog is primarily about agile software development and related topics such as lean thinking and the theory of constraints.
• AgileKiwi Overview of Agile Software Development

Scrum in 5 Minutes
On my laptop, I can run this PDF in full screen mode as a slide show and use it for press briefings or short overviews for those not familiar with Scrum, particularly when working on "Scrum for Everybody" for non-IT implementations.

I used it in a large press conference last week in Buenos Aires and the press feedback was very positive. They said it hit them at just the right level and that my responses to questions (working through a real time Spanish interpreter) were unusually direct and to the point every time. I told them that was a lesson in Scrum transparency. We want everything to be open, clear, and direct so that teams and companies can self-organize to improve performance.



Softhouse also has a nice graphic showing the Scrum process.

 

Read more of Jeff's post here: http://jeffsutherland.com/scrum/2006/11/scrum-in-5-minutes.html

 

Access the SCRUM in 5 Minutes PDF: http://www.softhouse.se/Uploades/Scrum_eng_webb.pdf

Jason Yip at ThoughtWorks recently updated his article on Daily Stand-Up Meetings for agile teams. This is an amazing, comprehensive article that details what daily stand-up's are for, their basic structure and how to make them work, and Jason also provides great troubleshooting advice and potential pitfalls to avoid. Here's the intro:

The daily stand-up meeting (also known as a "daily scrum", a "daily huddle", a "morning roll-call", etc.) is simple to describe: the whole team meets every day for a quick status update.  We stand up to keep the meeting short.  That's it.  But this short definition does not really tell you the subtle details that distinguish a good stand-up from a bad one.

Given the apparent simplicity of stand-ups, I was quite surprised the first time I saw one that wasn't working. It was immediately obvious to me what was wrong but I realised that it was not obvious to the team. I realised that my team was not aware  of the underlying principles and details that would allowed them to diagnose and solve problems with stand-ups.

People who have experienced good stand-ups will generally know what can be done when things aren't working well. For novice stand-up attendees, when things go wrong, it is much less likely that they'll figure out what to do. One way to approach this issue is to claim that it's all a matter of tacit knowledge and novices just need to attend more well-run stand-ups. I believe, however, that it's much more likely that given no assistance, novices will simply abandon the practice of daily stand-ups. This would be unfortunate since well-run stand-ups add significant value to projects.

This is my attempt to communicate some of the previously tacit knowledge on the benefits and consequences of common practices for daily stand-ups. These patterns of daily stand-up meetings are intended to help new practitioners as well as remind experienced practitioners of what they might already know in their gut.

Read more here: http://docs.google.com/View?docid=ajk9hjp2k4px_7dqc4t6

secondary URL: http://martinfowler.com/articles/itsNotJustStandingUp.html

This is an excellent article on daily stand-ups and is definitely worth the read!

I particularly liked a reply by Alan Shalloway that linked things back to W. Edwards Deming's 14 points for management from his Theory/System of Profound Knowledge. Allan's translation has a bit of a "Lean" slant to it, and doesn't explicitly mention eliminating/reducing variation quite so much. Here is how he summarized it:

Respect for people, the best place to start, IMHO, is Deming. Here are his fourteen points (Chapter 2 of Out of the Crisis, by W. Edwards Deming, MIT Press, 2000; originally published in 1982.):

1. The world has changed and managers need to adopt a new way of thinking. Delays, mistakes, defective workmanship and poor service are longer acceptable.
   
2. Quit depending on inspection to find defects and start building quality into products while they are being built. Use statistical process control.
   
3. Don't choose suppliers on the basis of low bids alone. Minimize total cost by establishing long term relationships with suppliers that are based on loyalty and trust.
   
4. Work continually to improve the system of production and service. Improvement is not a one-time effort; every activity in the system must be continually improved to reduce waste and improve quality.
   
5. Institute training. Managers should know how to do the job they supervise and be able to train workers. Managers also need training to understand the system of production.
   
6. Institute leadership. The job of managers is to help people do a better job and remove barriers in the system that keep them from doing their job with pride. The greatest waste in America is failure to use the abilities of people.
   
7. Drive out fear. People need to feel secure in order to do their job well. There should never be a conflict between doing what is best for the company and meeting the expectations of a person's immediate job.
   
8. Break down barriers between departments. Create cross-functional teams so everyone can understand each-other's perspective. Do not undermine team cooperation by rewarding individual performance.
   
9. Stop using slogans, exhortations and targets. It is the system, not the workers, that creates defects and lowers productivity. Exhortations don't change the system; that is management's responsibility.
   
10. Eliminate numerical quotas for workers and numerical goals for people in management. [We add: Eliminate arbitrary deadlines for development teams.] This is management by fear. Try leadership.
    
11. Eliminate barriers that rob the people of their right to pride of workmanship. Stop treating hourly workers like a commodity. Eliminate annual performance ratings for salaried workers.
    
12. Encourage education and self-improvement for everyone. An educated workforce and management is the key to the future.
    
13. Take action to accomplish the transformation. A top management team must lead the effort with action, not just support.

These go back 60 years. And (I can't help myself) these principles are in the context that process causes 94% of the errors - so work on the process to support the people! (people and process, people and process, people and process, ...) ;)

Read more here: http://bradapp.blogspot.com/2006/10/lean-view-of-demings-14-points-for.html

Thanks to Brad Appleton and his ACME blog for posting great information and his thoughts on Deming and Lean. Check out the link above for the complete post with references and links to other resources on lean, agile, XP, Scrum, Deming and more. Here are a few additional Deming related links:

• Deming's 14 Points - Deming first stated the 14 points in Quality, Productivity, and Competitive Position. Over time he continually revised them. The points are part of a system of management which Deming later described as the system of Profound Knowledge. The 14 points listed here are the list shown on the W. Edwards Deming Institute site.
• W. Edwards Deming's Fourteen Points - W. Edward Deming is generally recognized as being the philosopher-guru of the Total Quality Movement. Deming developed a set of Fourteen Management Principles and Seven Deadly Diseases in the early 1980s. There are various versions of the Fourteen Points in circulation. The version reproduced here is an early one that Deming handed out at his famous four-day seminars.
• W. Edwards Deming Institute - This site provides an exhaustive resource for exploring Deming's ideas and ongoing conferences discussing Deming.

Enjoy!

Scrum and XP from the Trenches
Henrik Kniberg has published a PDF called Scrum and XP from the Trenches. It's a well written and engaging read on his experiments, successes, and challenges running a development team of about 40 people using Agile methods.

One thing I found quite interesting was the information that his team felt was most useful to document user stories (or backlog items). They used various tools, including a shared Excel spreadsheet, to track the following:

• ID of the story
• Name/description of the story
• Importance/Priority of the story
• Initial estimate (in points or ideal days)
• How to Demo - a brief description of how the story will be demonstrated to stakeholders.
• Notes

Of these fields, the "How to Demo" is one near and dear to me. It's basically a narrative around what exactly you would do to verify that the story is working in such a way as to communciate it clearly to the customer.

Perhaps even more critical, though, is that by writing out how they plan to demo a feature, the team is forced to write out their assumptions, which can then be quickly challenged by the customer.

For example, in a toy store application, a story might say "Add games to the catalog". The "How to Demo" might read: "Log in, select the Add Game menu, and enter the details in a form. Verify the information gets stored in the DB".

A customer might then see the estimate as 2 weeks, and say "No, no, I don't care if you enter the information manually in the database, we don't need a form and fancy input screens yet."

This is commonly referred to as an "acceptance test" in XP literature, but is often forgotten by teams just starting out with Agile. This simple tool can greatly improve your communication with the customer, and help avoid misunderstandings.

 

Read more of Churchville's post: http://www.extremeplanner.com/blog/2006/11/scrum-and-xp-from-trenches.html

Read more of Kniberg's article (PDF): http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf

XP and Scrum tend to focus on different aspects of software development.  Scrum has more agile management and agile organizational concerns and XP has more agile engineering concerns.  Both practices together form a more complete picture of agile software development.  They are parts of a larger puzzle.  Agile projects are at their best when agile management abilities and agile engineering abilities are meaningfully in play.

Scrum is often introduced into an organization from the top-down; starting from project or organization leadership and communicated ultimately to front-line, tactical staff like programmers, testers, infrastructure people, etc.  XP has traditionally come into organizations from the bottom-up; starting with front-line tacticians programmers who introduce sustainable development practices and then expand the practice set upward until it encompasses management people and practices.

Depending on which methodology enters an organization first, and transitively which end of the authority chain is first to adopt, certain agile practices are likely to show up before others.  If Scrum is brought in before XP, management and organization practices typically show up first.  If XP is brought in first, engineering practices like developer testing, continuous integration, and behavior-driven design practices often show up first.

An agile project team should be vigilant toward imbalances between the value that Scrum and XP bring to a software project.  Scrum and XP aren't drop-in replacements for each other.  It's not difficult for an organization with its roots in XP to unwittingly become unbalanced toward engineering practices to the detriment of agile management, and for for an organization with its roots in Scrum to unwittingly become unbalanced toward management practices to the detriment of agile engineering.

Read more here: http://codebetter.com/blogs/scott.bellware/archive/2006/11/28/155508.aspx

Some interesting thoughts on SCRUM and XP - particularly regarding the need to maintain a flexible balance between agile management and agile engineering, rather than leaning heavily towards one or the other. Be sure to check out the complete post - Enjoy!

posted by Raven at Raven's Brain under Agile
Tags: Project Management, Agile, Agile Project Management, Agile Development, SCRUM, XP, Agile Methods

10 Mistakes in Transitioning to Agile
Mistake 1: Go All In

Months of discussion and e-mail threads are finally gone and it's been decided that agile is the right thing for your organization. Be bold. Do not start with a pilot project; that's for people who have all the time in the world. You run multiple projects and you have no time—pick a big and risky project or force this new methodology to all projects simultaneously. If you find yourself looking for a good disaster candidate, try to find the one with a new technology and/or a tight deadline. Because you won't have time to learn from mistakes, something pilot projects are specifically conducted for, you'll multiply them in all teams putting your agile initiative in life support.

Mistake 2: Go Fast to Go Fast

Do not take the time to get your group and other groups within your organization to understand agile development. Especially if you're also growing fast and creating new departments, do not slow down and throw them into the mix. For example, say you just established a new User Experience group. Before you even have time to define the new group's roles, throw them into the agile initiative.

Make sure you don't clearly define the terminology, such as the similarities and differences between use cases and user stories. This way, everybody will have a different idea of what is being created and that will contribute to the overall confusion.

Mistake 3: Ignore the Corporate Culture

What is corporate culture? Things such as:

 

The way projects are managed (estimation, project planning and monitoring, scope management, and so on).
Teamwork versus individual heroism.
Employee attitude. Brave and aggressive, innovative, and risk-taking or conservative and protective.
Departmental relations and politics.
Fun and learning.
Pace of development.

Agile development is based on teamwork and cross-functional teams. Many organizations are composed of departments and sometimes walls exist between them. While forming the agile team, make sure to ignore or overrule the existing departmental boundaries. This helps you alienate department heads and quickly take their support away.

Mistake 4: Fail to Identify the Sponsor

This is different than project stakeholders. This is more like the person who pays the bill and, at the end of the day, needs to be convinced that agile works. Fail to identify and engage them early and often and you guarantee the day they'll come and ask for the return of their investment. For example, you have a body of use cases produced over a period of a year. You find out that they are not good enough and direct the team to either rewrite a portion or convert them to user stories. Because this is a time-consuming process, do not communicate that to the sponsors so that when they ask what happened to the old use cases, you have nothing to say.

 

Mistake 5: Fail to Define Roles Within the Agile Team

Do not define the roles of each team member. This creates confusion within and outside the team that keeps everybody messed up for the time to come. This also helps in the rise of agile supercoaches, a new breed of Swiss-Army-knife-type people that, among other things, can do project management, coding, architectural design, training, and more.

Mistake 6: Do Not Create a Project Plan Before the First Two Iterations

Mistake 7: Overdo the Team-Room Concept

Mistake 8: Trash All Computer-Based Project Management and UML Tools

Mistake 9: Choose Your Key People Poorly

Mistake 10: Make Agile the New Religion

 

Read the complete article here: http://www.ddj.com/dept/architect/193402902

Regardless of company size or market sector, businesses today invest in projects to sustain or advance competitive advantage. Many of the information technology projects are attempting to use Agile Project Management to reduce the risk of IT projects, and to deliver value to the business early. Even when using Agile project management practices, the reasons for project failures are usually predictable. There are five key causes contributing to projects collapsing before realizing their true potential. Break the cycle of challenged projects by focusing on these key areas.

 

The five deadly sins of Agile Project Management: 

1. Failure to conduct pre-project business analysis and ongoing project evaluation
2. Failure to conduct a formal project kick-off
3. Failure to maintain the core team
4. Failure to manage the project value throughout the project life cycle
5. Failure to manage the project benefits

1. Failure to Conduct Pre-Project Business Analysis and Ongoing Project Evaluation

Portfolio management, managing the demand for IT projects, provides management with a view of projects across the enterprise, which facilitates project investment decisions. To ensure that strategic goals are achieved, strategies are translated into tangible programs and supporting projects through the portfolio management process. By aligning investments with projects that deliver outcomes to achieve strategic goals, portfolio management leads directly to improvements to the bottom line.

 

Studies show how pervasive this new management process has become. In a 2005 study of 54 senior-level decision makers by the Center for Business Practices in Havertown, Penn., 57.4 percent of the respondents reported that portfolio management helped their organization improve focus and work on the right projects. In addition, 70.4 percent said it improved their project alignment with their organizations’ overall strategy.

 

So what does this have to do with Agile Project Management? For the portfolio planning team to work effectively, it needs the support of senior business analysts and project managers to provide them with solid information from industry analysis and feasibility studies. However, the Agile team is all about reducing analysis and getting down to the development and delivery of the solution components. The wise business analysts and project managers spend ample time analyzing the business problem and the feasibility of potential solutions to ensure the project is delivering the most valuable solution option.

 

Read more here: http://www.gantthead.com/article.cfm?ID=233708