Raven's Brain v1.0: Agile

Insights On Agile, Software Development and Tech Execs

Thu, 10 Jan 2008 23:16:53 GMT

Brad Appleton has a great post titled What do you wish your CEO knew about Agile? In it he provides some great thoughts for tech execs in the agile software development world and references some great insights from Steve McConnell. Here's a great clip:

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.

posted by Raven Young at Raven's Brain under Agile

Tags: Agile, Agile Software Development, Agile Methods, Agile Management

Agile Software Development vs. Agile Project Management

Thu, 26 Jul 2007 00:28:47 GMT

Glen of Herding Cats has two good posts questioning and discussing the subject of Agile Software Development vs. Agile Project Management:

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

Well worth the read if you are a project manager interested in or working with all that is "agile". Even though there is an agile alliance, the agile manifesto, numerous agile focused blogs and website,s and many more agile related resources out there, you will often find disagreement on what IS agile. Sure, there are a ton of opinions but no single opinion should be considered without researching other points of view (since there is so much disagreement on the subject). If you've found yourself asking "what IS agile?" or want to learn more about some of the points of contention - read, research, process the information and repeat until you have a better understanding of what you are trying to accomplish WITH agile and what method, processes and tools to use to get there. Here are a few related posts and other resources on the subject:

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

posted by Raven Young at Raven's Brain under Agile

Tags: Agile, SCRUM, Agile Project Management, Agile Software Development, Agile Methods, Agile Management

Agile Insights: Scrum is Team-Driven Development

Mon, 11 Jun 2007 17:06:58 GMT

The Agile Executive Blog has a brief and interesting post making the case for using Scrum: Scrum is Team-Driven Development. Here is an excerpt:

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.

posted by Raven Young at Raven's Brain under Agile

Tags: Agile Management, Agile, SCRUM, Agile Project Management, Agile Methods

Agile Insights: A "Post-Agilism" FAQ and Agile variations

Wed, 02 May 2007 04:12:16 GMT

Interesting, thought provoking posts at pliantalliance on emerging agile thoughts: The Post-Agilism FAQ:

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

I found both posts quite interesting and found myself thinking deeper about the agile monster. With the recent rumblings in the agile community about updating/revising the Agile Manifesto and other folks, like JK, tbeck thinking beyond agile, it's clear that change is coming to the original agile mind set. I read a related post earlier today by Skip Angel where he discusses various agile methods and suggests using a cut-and-paste approach to agile implementation, rather than sticking one one single method like FDD, XP, SCRUM, etc. From An Agile Approach to adopting Agile:

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

All great thoughts on agile, where it's at and how the various methods are growing. One thing is for certain, agile works and it's just a matter of finding the right pieces that are a good fit for your organization. Opinions may vary on the rigidity of methods, manifesto's and guidelines, but by researching, taking a slow approach and ramping up once your practices and processes are in place you'll be better able to determine what works, what processes are needed and what wastes time, and what might be missing for your particular org.

See related post:

Agile Insights: When is Scrum not Scrum?
http://ravenyoung.spaces.live.com/blog/cns!17376F4C11A91E0E!3457.entry

posted by Raven Young at Raven's Brain under Agile

Tags: Agile Management, Agile, Agile Manifesto , Post-Agilism, XP , SCRUM

Agile Insights: Should the Agile Manifesto evolve as we learn more about agility?

Mon, 30 Apr 2007 18:05:55 GMT

Simon Baker has an interesting post on a current debate in the ever-growing agile world: Does the Agile Manifesto need refactoring? Should it be extended? It provides some great insight on the arguments surrounding an update of the now 6 year old Agile Manifesto and gives food for thought on allowing the AM to evolve:

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**

posted by Raven Young at Raven's Brain under Agile

Tags: Agile Management, Agile, Agile Manifesto

Agile Insights: When is Scrum not Scrum?

Tue, 27 Mar 2007 02:39:13 GMT

Agile Thoughts has a post titled When is Scrum not Scrum? that's getting a lot of attention from agile bloggers (just check out the comments!). It's written by agile blogger Tobias Mayer and discusses his experience in using and teaching Scrum and various deviations from the traditional Scrum methodology he uses to be more effective. It's an interesting piece - here's the intro:

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?

For bonus reading, browse the comments following the post to get more opinions and thoughts on different ways of implementing Scrum. Again, an interesting read on Scrum and one that will indeed have you asking, and perhaps answering back?, when is scrum not scrum? Good stuff!

posted by Raven Young at Raven's Brain under Agile

Tags: Agile Management, Agile, SCRUM, Agile Project Management, Project Management

Agile Insights: The hardest part of being an Agile Project Manager

Sat, 24 Mar 2007 00:30:42 GMT

Brian Button has some interesting insight on being an Agile PM in a post titled The hardest part of being an Agile Project Manager. Here's a blog-byte:

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!

posted by Raven Young at Raven's Brain under Agile

Tags: Agile Management, Agile, SCRUM, Agile Project Management, Agile PM, Agile Project Manager, Project Management

Agile Insights: The Managers Role In Scrum

Sat, 24 Mar 2007 00:20:06 GMT

Jeff Sutherland, one of the two inventors of Scrum, has an interesting post titled The Managers Role in Scrum. Some interesting points:

"...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

posted by Raven Young at Raven's Brain under Agile

Tags: Agile Management, Agile, Scrum, Agile Management, Jeff Sutherland, Agile Manager

Agile Thoughts: Re-thinking what makes a project successful

Thu, 15 Mar 2007 00:40:33 GMT

Skip Angel has an interesting agile post from last month titled Re-thinking what makes a project successful. It's a great read and made me ponder what "success" for a project really means in today's increasingly agile world of software & web development development. Here's a clip:

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

Here are a few more agile posts of Skip's I've tagged and haven't had time to post - all great stuff!

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

posted by Raven Young at Raven's Brain under Agile

Tags: Agile Management, Agile, Agile Projects, Agile Project Management, Project Success

Excellent Agile Post - Emotional Intelligence: A Key Element of Scrum

Sun, 18 Feb 2007 20:37:23 GMT

The Agile Business Blog has an excellent post titled Emotional Intelligence: A Key Element of Scrum. If your looking at moving Agile or are just researching some benefits, you gotta check out this post. Here's a snip:

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!

posted by Raven Young at Raven's Brain under Agile

Tags: Agile Management, Agile, SCRUM, Agile Project Management, Scrum Teams, Scrum & Emotional Intelligence, Emotional Intelligence

Ditto! Cool site: Implementing Scrum

Sun, 11 Feb 2007 18:25:24 GMT

I stumbled onto this site a while back and was bummed I hadn't saved the URL. Then I came across a post by Mishkin Berteig over at the Agile Advice blog:

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!

I recently received a nice email from the site creator Michael Vizdoz and went back to check it out some more. Here is a great comic from the site - you'll have to visit for yourself to get the context, details and additional Scrum info and related resources:

Link to cartoon: http://www.implementingscrum.com/cartoons/implementingscrum-20061211.html

Be sure to scroll down to read the detail for this one!

Link to Blog: http://www.implementingscrum.com/cartoons/cartoons.html

Link to Cartoons: http://www.implementingscrum.com/cartoons/index.html

Great stuff Michael - keep it going!

posted by Raven Young at Raven's Brain under Agile

Tags: Agile, SCRUM, Agile Project Management, Implementing Scrum, Scrum Master

Agile Post: Breaking the Iron Triangle: Project Manager v Scrum Master

Sun, 11 Feb 2007 18:08:16 GMT

I loved this post by Steve Garnett on the traditional PM role and Scrum Master:

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

What great insight into a project manager turned scrum master and the challenges faced! If I've learned one thing about all things agile, including Scrum, is that implementation varies from org to org, or even from departments or groups within the same company. So the model discussed in the post above may not be 100% relevant for your particular company, but it should provide insight on what a traditional project manager might face when implementing Scrum. Good stuff and thanks to Steve at the Agile Business Blog for the great info!

posted by Raven Young at Raven's Brain under Agile

Tags: Agile Management, Agile, SCRUM, Agile Project Management, Implementing Scrum, Scrum Master

More SCRUM Resources: Scrum Roles & ScrumMaster explained plus tons of Scrum & Agile links

Tue, 30 Jan 2007 20:09:36 GMT

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

Check out my previous Scrum post for more Scrum info from Ken Shwaber. There are great video clips of Ken explaining different aspects of Scrum and excellent info on topics like Scrum Basics, Preparation, Scrum Roles, Processes, SCRUM Artefacts/Tools, SCRUM FAQs, Product Burndown, Product Increment, Bug Priority, History and Count, Sprint Overviews and details, Handling Product and Sprint Backlog items, Impediment reports, and tons more. Thanks to Scrum For Team Systems for the excellent info!

posted by Raven Young at Raven's Brain under Agile

Tags: Agile Management, Agile Methods, Agile, SCRUM, Agile Project Management, Agile Development, Scrum Roles, Scrum FAQs, ScrumMaster, Sprint Overview, Scrum Artefacts

Agile Info: SCRUM in Five Minutes PDF, excellent overview

Tue, 23 Jan 2007 03:16:28 GMT

Jeff Sutherland has a post that references a great SCRUM in Five Minutes PDF:

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

Excellent information! Thanks to Jeff for the reference and to SoftHouse for the excellent SCRUM resource.

posted by Raven at Raven's Brain under Agile

Tags: SCRUM in 5 Minutes, SCRUM, Agile Development, Agile Management, Agile Methods

Great Resource For Agile Teams: Jason Yip's Updated Article on Daily Stand-up Meetings

Tue, 23 Jan 2007 02:36:17 GMT

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!

posted by Raven at Raven's Brain under Agile

Tags: Daily Standup, SCRUM, Agile Development, Agile Teams, Agile Management, Agile Methods, Daily SCRUM

Good Agile Post: Lean view of Deming's 14 Points for Management

Mon, 08 Jan 2007 05:55:03 GMT

Brad Appleton has a great post tying in Demings 14 Points for Management to the agile world:

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.):

The world has changed and managers need to adopt a new way of thinking. Delays, mistakes, defective workmanship and poor service are longer acceptable.

Quit depending on inspection to find defects and start building quality into products while they are being built. Use statistical process control.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Encourage education and self-improvement for everyone. An educated workforce and management is the key to the future.

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!

posted by Raven at Raven's Brain under Agile

Tags: Lean Management, Agile, Agile Project Management, Agile Development, SCRUM, Agile Management, Deming, Deming on Management

Agile Management & Project Planning: Scrum and XP from the Trenches PDF

Tue, 19 Dec 2006 20:20:10 GMT

David Churchville has a good agile post with a summary of an interesting agile and project management article:

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

Both the article and post are worth checking out if you're looking for some real world agile advice. Good stuff. Thanks to David and Henrik for the great info! As always, leave a comment if you have a related resource or have something to add to the discussion. Enjoy!

posted by Raven at Raven's Brain under Agile

Tags: Agile, Agile Project Management, XP, SCRUM, Agile Management, Agile Methods