Jeff Sutherland is well known as one of the co-creators of Scrum, one of the leading agile development methodologies.

In this video, Jeff talks about his visit to Google - where he analysed one of their first implementations of Scrum on one of their largest distributed projects - and shares the lessons they learned...

Agile Project Management: Lessons Learned At Google


P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...

read more

I read this blog post from Tobias Mayer that compares Scrum with Alchoholics Anonymous... It made me laugh out loud! :-)

read more

I found this article on Agile Journal really interesting:

Why 'General Agile' Isn't Enough - Why Scrum Wins in the Enterprise.

I have to say, I agree with Katie's points entirely...

We have implemented Scrum in a large web development group that is now about 120 people.

The simplicity of Scrum. The high visibility. The collaborative approach. The frequent delivery of product. All in all, Scrum really did transform the relationship between IT and the business units. And transformed our ability to deliver.

Kelly.

P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...

read more

When you first implement Scrum, it can be HELL!

Sure, if you start with an established team, where the majority of the team has been trained in Scrum or done Scrum before, and you're working on BAU (Business As Usual) development, it's reasonably straightforward.

If you have a free choice about where to start implementing Scrum, I would highly recommend starting *there*.

But...

If you have a newly formed team, where the majority of the team has not done Scrum before or been on Scrum training, and you're working on a ground-up development project, implementing Scrum can be a painful and frustrating experience for everyone involved!

I have seen this situation quite a few times now. And without fail the experience seems to be the same.

Almost as much time is spent discussing the process and how things should be done as actually doing it. The product backlog is confusing and disorganised. Requirements are not clear. User Stories are not adequately prepared. Sprint Planning takes *days* instead of hours. And we all know how much developers love sitting in meetings!

Here are a few tips for handling this common situation...

First and foremost, get your backlog in order! In my series about 'implementing Scrum in 10 easy steps', this is step #1 and the most important step. Here I say you should proceed no further until this step is completed, otherwise you'll regret it. It's true, believe me! :-)

Accept the fact it will take your team at least 3 or 4 Sprints to get into any sort of rhythm. Refine how you handle the process in each Sprint.

Resist adapting the process.

Ken Schwaber is the father of Scrum. Ken makes a very good point about this in his book 'Agile Software Development with SCRUM'. Scrum is designed to be adaptive. That's actually a key principle behind the method: 'Inspect and Adapt'. But until you understand a process well, and have some experiencing executing it as intended, you are in no position to adapt it.

Persevere. Trust me, it's worth it.

Apart from the usual issues when a group of people adopt a new process they aren't yet familiar with, newly-formed teams have their own challenges to overcome. According to research, a newly-formed team goes through some specific stages of team formation and only after some time does the team really begin to gel.

These stages are: forming, storming, norming, and performing. Follow the link to see a full description. It really is a very interesting concept and is worth understanding.

During the forming stage, "supervisors need to be directive". This is in direct conflict with a key principle of Scrum, which is 'self-organisation'; the idea that the team is empowered and makes its own decisions. Until the team has properly formed, and the process has been established, the team is not in a position to do this.

During the storming stage, team members become more assertive and confront their colleagues with their views. This stage can be contentious, unpleasant and even painful to members of the team who are averse to conflict. Going through this stage whilst still learning how to execute Scrum effectively is what I would refer to as 'Scrum Hell'. It's difficult. But it's not possible to skip this stage. Human nature demands it.

The norming stage is where team members start to adjust their behaviour as they learn to work together as a team.

Some, but not all, teams will reach the performing stage.

These high-performing teams are able to function as a unit as they find ways to get the job done smoothly and effectively, without inappropriate conflict or the need for external supervision. Team members have become interdependent. By this time they are motivated and knowledgeable. The team members are now competent, autonomous and able to handle the decision-making process without supervision. Dissent is expected and allowed as long as it is channelled through means acceptable to the team.

Then, and possibly only then, is the team is truly capable of self-organisation.

See here for further information on How to implement Scrum in 10 'easy' steps...

Kelly.

P.S. Click one of the icons below to join the growing community of people reading this blog by RSS or by email...



Photo by Luis Fabres

read more

Here are some useful resources for new Scrum Masters or Scrum Masters to be...

* How To Implement Scrum

* Certified Scrum Master Training

* Scrum Study Guide (free demo)

* Ask the Scrum Community

Enjoy!


P.S. Click one of the icons below to join the growing community of people reading this blog by RSS or by email...



Photo by benleto

read more

So you've had enough of failed projects. You like the sound of agile development as an alternative. You buy into the key principles and you're ready to take the plunge.

Which methodology should you go for?

I don't have any official stats on which agile methodologies are most widely used, but there certainly seems to be much more of a buzz about eXtreme Programming and Scrum, at least on a global basis.

So which is right for you, eXtreme Programming (XP) or Scrum?

I've heard people ask this question. I've heard people talk about them as though they are mutually exclusive choices. But really they are not.

eXtreme Programming and Scrum are so different they are not really comparable.

They share the same underlying values described in the agile manifesto, and the same underlying principles that characterise 'agile'. They overlap in areas, but fundamentally they address completely different aspects of software development.

Scrum is an agile management methodology. Whereas XP is an agile engineering methodology. As such they are entirely complementary.

If your motivation for agile is wanting more visibility, better business engagement, team collaboration, a clear process for prioritisation, etc - Scrum is for you.

If your motivation for agile is simplification of requirements management and improved product quality, XP is for you.

In both cases you will benefit from a more incremental, iterative approach to development.

In my experience, Scrum is the more likely starting point when the adoption of agile is driven by management. XP is the more likely starting point when the adoption of agile is driven by developers.

In my view? Ideally you would do both. Or at least elements of both. And you would start with the one that addresses the issues causing you to adopt agile in the first place.

Kelly.

P.S. Click one of the icons below to join the growing community of people reading this blog by RSS or by email...



Photo by i-plus

read more

I was intrigued by this article from InfoQ about the role of ScrumMaster as a blocker.

Personally, I hate office politics.

I think they're are complete waste of time. They zap my energy and leave me feeling frustrated and angry.

I guess there's an argument here that playing political games protects the team from people that don't buy into the team's approach.

I can kind of see their point. But encouraging such a political approach seems to be a bad idea to me. If you can't debate the pros and cons of an approach - and win or lose the argument on an open and professional basis - I don't think this is the answer.

read more

A software release may result from multiple iterations (or 'Sprints' in Scrum).

Sprint Planning is about planning what's included in the next iteration.

Whereas Release Planning is about planning multiple Sprints, in order to predict when a release (or releases) might be delivered.

Release Planning is a very simple way of doing some top-down planning. Much less complex than a more traditional project plan on a Gantt-chart. Therefore much quicker to do. And, I would say, no more or less accurate.

First of all, let's assume you already have your Product Backlog (feature list), with all your User Stories set out in priority order. Let's also assume that you've estimated your product backlog, ideally using Story Points.

If you already have an established team doing Scrum or XP (eXtreme Programming), use the team's known Velocity to divide the Product Backlog into Sprints.

However, if the team is not already using Scrum or XP, you need to estimate the team's Velocity. To do this, you must first make an assumption about the team size that is likely for the release. Then, you need to decide on your Sprint duration and, ideally with the input of the team, decide how many of the initial User Stories you think could reasonably be achieved in a Sprint. Add up the Story Points for these items. Using this number of Story Points as the team's estimated Velocity, divide the Product Backlog into Sprints.

If the project team is not already established, add a 'Sprint Zero' at the beginning to get things ready for the first Sprint, for instance getting the team organised, briefing meetings, setting up development and test environments, preparing the first set of User Stories, etc.

If it's a large or complex release, add a 'Stabilisation Sprint' (or more than one Sprint if appropriate) at the end to stabilise the release. By this, for instance, I mean stop adding new features, complete regression testing, bring the defect count down to an acceptable level, prepare for deployment, etc.

If the predicted end date is not acceptable for the project's objectives, alter the assumption about the team size (and associated costs!) and re-calculate.

And there you have it! A Release Plan that provides an outline of the Sprints, what's included in each, and an estimated date for the release.

read more

In my opinion, ScrumMaster Certification isn't worth the paper it's written on.

Don't get me wrong, I'm a big fan of Scrum. Huge fan. It's really helped to transform the web development department I head up.

And I'm not getting at the training companies that deliver Certified ScrumMaster training either. Nor the people that go on the training.

But I do have a problem with the marketing of this training as 'Certified ScrumMaster'. Because, to me, this phrase is completely misleading.

Over the years, I have come to think of the word 'Certified' as implying some depth of experience or knowledge. Maybe the passing of an exam following a period of study. Maybe a vocational assessment of someone's ability in the workplace. Something that validates a person's capability in the subject meets a minimum standard.

But with Certified ScrumMaster training, there is no assessment or exam. No prerequisites for attending the course. No previous project management experience required. No study required. Simply attend a 2 day ScrumMaster course and you are a Certified ScrumMaster.

Secondly, the word 'Master' compounds the problem further.

I understand the word 'Master' in ScrumMaster means 'master of ceremonies'. That's completely logical and makes perfect sense. However the word 'master' also happens to mean someone of 'great and exemplary skill, a worker qualified to teach others and carry on the craft independently; an expert in their craft'.

So, would you not really expect a Certified ScrumMaster, or a Certified Master in any craft, to be someone at the top of their trade? Not someone who received a certicate of attendance following 2 days training.

Calling it Certified ScrumMaster is a master class in marketing. And unfortunately I think it undermines Scrum - a methodology that otherwise can offer huge advantages to development teams of all disciplines.

So is Certified ScrumMaster status worth having?

Is it worth going on the training? Of course. Is it worth quoting your Certified ScrumMaster status to current and potential employers? Possibly not.

Sure, as a company practicing Scrum, I'm interested in people with Scrum training and experience. But as an employer practicing Scrum, I also recognise Certified ScrumMaster status for what it is. And in that respect, it isn't worth the paper it's written on.

read more

So you’ve got your backlog in order, estimated your backlog, clarified your requirements, planned your sprint and created a collaborative workspace.

You've sprinted to achieve your sprint goals, run daily stand-up meetings and tracked progress with a daily burndown chart.

Now you've come to the end of your Sprint and finished when you said you would. All that's left to do now, is Review, Reflect and Repeat...

Sprint Review

At the end of the Sprint, hold a Sprint Review meeting. Invite the whole team. Invite all the key business stakeholders. Invite senior stakeholders including executives where appropriate. The more interested parties the better!

Review what was delivered in the Sprint. Demo the software. Whether it's complete, working software prior to a release, or work-in-progress in a long-running multi-Sprint project, demo what has been completed in the Sprint. Let team members demo the areas they have worked on.

The purpose of the Sprint Review is three-fold:

1. It allows team members to show what they've achieved and demonstrate their contribution to the product.
   
   
2. It allows all key stakeholders to see what's been done, and provide valuable feedback on a regular basis, while there's still time to take it on board.
   
   
3. It helps the team to stay focused on the deadline of the Sprint - no-one wants to show up at the Sprint Review with nothing useful to demo.

Sprint Retrospective

Following the Sprint Review, hold a Sprint Retrospective meeting. Invite the whole team. Invite the Product Owner. But this meeting is not for the wider stakeholders. Typically it might follow on immediately from the Sprint Review.

The purpose of the Sprint Retrospective is to reflect on how things went during the Sprint. It's a chance for the team to discuss the Sprint and consider how they could improve things.

Together the team should:

• Review the final Burndown Chart. How did it go? Did the team deliver what they committed to at the start of the Sprint? Note the outstanding hours in a spreadsheet so the team's success rate can be plotted on a graph over time, to see if it's getting better or worse. This is a tool for the team to gauge its progress by. It's not a stick for management.
  
  
• Review the team's Velocity? Velocity is the number of points estimated on the original product backlog, for the items *completed* in the Sprint. Only items 100% complete and delivered, signed off, in the software count in the team's Velocity. Again, plot this on a graph so the team's Velocity can be tracked over time, so the team can see if it's delivering more or less as time goes by. Velocity will gradually settle around a norm, and can then be used in Sprint Planning as a gauge for how much the team could realistically achieve, based on their track record.
  
  
• Discuss what went well? (try to make sure it's repeated next time)
  
  
• Discuss what could have gone better? (try to understand why)
  
  
• Decide what the team will do differently in the next Sprint? (try to pick a few actionable points that can actually be done differently immediately in the next Sprint)

This is a continuous learning process.

Traditional project management methods, such as PRINCE2, also encourage continuous learning, through the production of a lessons learnt report on closure of the project.

The trouble with this is people don't always remember enough by the end of a long project. Or perhaps there is so much to reflect on at the end of a large project, that there are too many things to consider and the result just isn't actionable. And often on completion of a traditional project, the project team disperses onto other projects or back to where they came from, preventing them from applying their learnings as a team.

In Scrum agile development, like the product development itself, the learning is in small, bite-sized chunks. Little but often. While there is still time for the feedback to have a positive impact on the project.

Repeat

The team is now armed with valuable information - about the product, about their performance, and about some of the impediments in their environment, e.g:

• How the software looked after the last Sprint.
• Feedback about the product developed so far.
• To what extent the team was able to deliver what it committed to in Sprint Planning.
• The team's Velocity and what is achievable in a typical iteration.
• What went well.
• What didn't go so well.
• What will be done differently going forward.

All that's left for the team to do now, is repeat the process, with the greater knowledge gained from above.

Realistically it takes 3 or 4 Sprints for the team to get into a rhythm. To apply the improvements and get used to the process. For the Velocity to settle around a norm. And for the team to gel...

That's all folks!

So that's it! That's basically Scrum, and how you can implement it in 10 easy steps.

Of course, in reality, the steps aren't all that easy. The steps involve humans. And software development. Tricky combination!

Nevertheless, the Scrum process is inherently easy. And depending on your situation - certainly in my experience - Scrum and agile development can help your success rate in many many ways.

Follow my blog by email

See also:
How to implement Scrum in 10 easy steps:
- Step #1: Get your backlog in order!
- Step #2: How to estimate your product backlog
- Step #3: Sprint Planning/clarify requirements
- Step #4: Sprint Planning/estimate tasks
- Step #5: Create a collaborative workspace
- Step #6: Sprint!
- Step #7: Stand up and be counted!
- Step #8: Track progress with a daily burndown chart
- Step #9: Finish when you said you would
- Step #10: Review, reflect, repeat...

'Implementing Scrum' PowerPoint Presentation

10 Key Principles of Agile Software Development

read more

So you’ve got your backlog in order, estimated your backlog, clarified your requirements, planned your sprint and created a collaborative workspace.

You're sprinting to achieve your sprint goals, running daily stand-up meetings and you're tracking progress with a daily burndown chart.
Now you just need to finish when you said you would...

read more

So you’ve got your backlog in order, estimated your backlog, clarified your requirements, planned your sprint and created a collaborative workspace. You're sprinting to achieve your sprint goals and running daily stand-up meetings. Now you're ready to track progress with a daily burndown chart...

"Oh dear, it seemed to be going so well"

Often in traditional development projects, everything seems to be going so well, right up to 80% completion or perhaps even later. Then things start getting harder. Things start looking less and less likely to meet the planned end date. Until eventually you concede that you can't hit the date because it's just too late to do anything much about it...

Agile principles help

In agile software development, there are a few key principles that highlight issues early. Distressing though this is, the issues are highlighted whilst there's still time to do something about it.

One reason why this is a common problem in traditional software development projects is because the testing is one big lump all at the end. Consequently it's very hard to gauge quality until late in the day and it's very hard to judge how complete the product really is, because you don't know how many more bugs there are to find.

In agile development, testing is integrated throughout the lifecycle, features are completed one by one, and for each feature "done" really means "DONE!".

In addition, the Product Owner or user representative is actively involved in order to see the product frequently and steer its development every step of the way.

All of these principles, along with the daily stand-up meeting, go a very long way to ensuring clear visibility of progress, and providing a clear and unambiguous measure of the product's quality and completeness on a very regular basis.

Daily Burndown Chart

But in addition to these principles, the Scrum agile development method also offers a simple practice to track progress daily - the daily burndown chart, which beats any traditional project status report hands down in my view!

The daily burndown chart is a simple tool. But a very powerful one.

'Estimate To Complete'

Take all the tasks to be delivered in a particular Sprint in Scrum, i.e. your Sprint Backlog you created in step 4. On your Sprint Backlog, enter the estimated time to complete, which of course at the beginning of the Sprint is the same as the original estimate.

Update the estimated time to complete (ETC) each task on a daily basis.

Team members take responsibility

Each team member can be responsible for updating their own ETC's on a daily basis before the Scrum. Updating it daily - and sharing the effort amongst the team - means typically there should only be 2 or 3 items to update for each person each day. Therefore it should not be onerous and means team members take responsibility for their own tasks


Be honest about what effort you believe is required to complete each task (and that's the effort needed to really complete each task), regardless of how long has been spent to date and regardless of what was estimated in the first place.

Team goal

The team's goal, quite simply, is for the team to reach zero hours to go, by the end of the Sprint duration.

Plot progress visually on a graph

The beauty of this approach is that it's a numeric view of progress and can therefore be plotted visually on a graph. Plot the original estimates for the Sprint on one line, and the current estimates to complete on another line.

When the actual line tracks below the original estimate line, you're on track. When it tracks higher, you're running behind. It really is as simple as that. Highly visual, instant feedback for the whole team.

Annotate with key events

I've also found it useful to annotate the graph with 'speech bubbles' describing key events along the way. This is a useful way to record significant events so they're not forgotten by the time of the Sprint review.

It's also useful to communicate important things to management and stakeholders instead of producing a separate status report.

Scrum highlights your problems - it doesn't solve them

Using a burndown chart, when you spend one day on a task and discover a whole load of problems or effort you hadn't anticipated or estimated for, the estimate to complete jumps up, creating an all-too-visual indicator of the problem for all to see.

When this happens early in a project, and/or on a large scale, believe me it's pretty scary! Suddenly you're not so sure about all this new-found visibility! It seemed like such a good idea at the time, but can you really stick *that* burndown chart on the wall?!

True picture

But you do gain one big advantage. One enormous advantage.

You get to see where the project really is, every day, in all its techni-colour glory!

And when you hit problems in a project, you actually see them. And see them when you might just have time to do something about it.

Next, finish when you said you would...

Follow this series by email

See also:
How to implement Scrum in 10 easy steps:
- Step #1: Get your backlog in order!
- Step #2: How to estimate your product backlog
- Step #3: Sprint Planning/clarify requirements
- Step #4: Sprint Planning/estimate tasks
- Step #5: Create a collaborative workspace
- Step #6: Sprint!
- Step #7: Stand up and be counted!
- Step #8: Track progress with a daily burndown chart
- Step #9: Finish when you said you would
- Step #10: Review, reflect, repeat...

'Implementing Scrum' PowerPoint Presentation

10 Key Principles of Agile Software Development

read more

So you’ve got your backlog in order, estimated your backlog, clarified your requirements, planned your sprint and created a collaborative workspace. You're sprinting to achieve your sprint goals; now you’re ready for Step #7 – Stand up and be counted!

read more

So you’ve got your backlog in order, estimated your backlog, clarified your requirements, planned your sprint and created a collaborative workspace. Now you’re ready for Step #6 – Sprint!

Agile teams must be empowered

The Scrum team makes its own decisions during the Sprint. The team is empowered. Every time a manager steps in and makes a decision for the team, they remove some responsibility from the team. If a manager keeps doing this, the team gradually - piece by piece - loses ownership, along with their commitment.

As a manager, the team must be given support, guidance, coaching and assistance. Not instructions. If necessary, the team should be helped to reach its own decisions. Facilitation becomes a key skill for agile managers. Using their experience and management responsibility to help the team do its job. Not to do the team's job for them. Agile management requires servant leadership. Ideally inspirational leadership. The team self-organises to achieve its goals. But self-organisation is not boundaryless.

Time waits for no man!

The timeframe - in this case the Sprint Duration - is fixed. You can add scope if you absolutely must, or add tasks if you discover they are needed. However changes in scope should be offset by compensating reductions in scope, i.e. removing something else from the Sprint.

If you finish early, include more scope, i.e. the next most important thing on the Product Backlog. If you look like you're going to finish late, you must reduce scope in order to hit the deadline.

done means Done!

In order to achieve a fixed timescale, it's imperative to make sure you complete one feature at a time before moving on to the next. You need to avoid reaching the end of the Sprint Duration with 90% of everything. 90% of everything allows you to deliver nothing. It's better to have 100% of something...

Testing is integrated throughout the lifecycle

Achieving completeness - to make sure something is really done before moving on - means testing must be integrated throughout the lifecycle. In agile development, whether using Scrum or not, the traditional development lifecycle of analyse, design, develop, test, is repeated on a feature by feature basis, rather than in big phases for the entire project or product.

Testing starts at the start of the Sprint. In fact, it starts earlier than that. It starts in Sprint Planning, as involving testers at the start helps to clarify requirements. Writing the tests before a feature is built, means developers have more of a tendency to build the code to pass. Test driven development starts here.

No interference please

Ideally, once a Scrum team has committed to a Sprint, they should be left to focus on delivering what they've committed to. Constant changes to priorities prevent a development team from being fully productive and in the worst case can prevent a development team from delivering at all.

If priorities must be changed during a Sprint, then so be it. However an equivalent piece of work must be removed from the Sprint to compensate.

Personally I like to educate Product Owners about the impact of chopping and changing by calculating changes at double the effort. This is because the new piece of work was not discussed in Sprint Planning etc, and therefore all this has to be done in addition to the effort to implement the change. Doing this mid way through the Sprint is very disruptive. So, if you must add 3 hours of development, you should take 6 hours out.

Aborting a Sprint

Aborting a Sprint is a very serious act and should be reserved for exceptionally rare circumstances.

Let's say the Sprint Goal is no longer applicable. Or something has come in that means we really need to re-focus the team completely. Or the Sprint or project is so far off track it really warrants a complete re-think. These are the kinds of events when you should consider aborting a Sprint.

Aborting the Sprint means literally abandoning it and going back to Sprint Planning to re-assess priorities and re-plan.

Hopefully this situation is very rare, and ordinarily your Scrum team Sprints successfully to achieve the Sprint Goal.

read more

So now you’ve got your backlog in order, estimated your backlog, clarified your requirements, and planned your sprint.

Now you’re ready for Step #5 – Create a collaborative workspace …

I know I called this series, ’10 easy steps’, but the first 4 steps are actually quite hard work! This one’s a breeze…

Whiteboard your walls

Cover your walls in whiteboards. You can’t have too many.

A whiteboard beats any software system and for many purposes. High level plans/roadmaps, key dates, design discussions, sketches of functionality, issues log, ideas, stats, status reports, topical posters, etc, etc. You name it, stick it on the wall!

Create a place for Collaboration

The whiteboarded area will be your team’s “collaboration hub”. A visibility wall. The centre of all team discussions. The place where the team meets every day (standing up). The place where you can get everything you need to know. At a glance.

Management by post-it note

Mark up a whiteboard with 5 columns. You can add more if you want to. But at least do these. Label the columns: Product Backlog, Tasks To Do, Work In Progress, Ready To Be Verified and Done!

On a post-it note or card, write the reference number and description of each Product Backlog item that is included in the current Sprint. Put these in the left-most column, 'Product Backlog'. These notes don’t need to fully describe the functionality or requirements. They're just reminders about what’s included in the Sprint, and indications of progress.

Then write up a note for each Task on the Sprint Backlog. Place the Tasks beside their relevant Product Backlog items, in the column labelled Tasks To Do.

When someone starts working on a Task, they should move it to the column labelled Work In Progress. When it's ready to be verified, move it to the next column. When it’s done, it should be moved to the Done! column (remember to define what your team means by done).

This will create unrivalled visibility for you, the team, the product owner and any other interested managers and stakeholders.

Touchy feely

In my opinion, no software tool can replace the board. People have a special tactile relationship with the board.

Like email compared with face-to-face communication, no tool will replace the sense of collaboration and teamwork this focal point provides.

Yes, it might be more efficient to use a software tool. But efficiency isn’t everything. Effectiveness is more important than efficiency.

This is so much more than a progress board. It’s an excuse for people to collaborate. And in development, where many people are not necessarily natural collaborators, it’s an important step to get the team talking. To get the team working together. As a team.

Next, Step #6: The team Sprints to achieve the Sprint Goal...

Follow this series by email

See also:
How to implement Scrum in 10 easy steps:
- Step #1: Get your backlog in order!
- Step #2: How to estimate your product backlog
- Step #3: Sprint Planning/clarify requirements
- Step #4: Sprint Planning/estimate tasks
- Step #5: Create a collaborative workspace
- Step #6: Sprint!
- Step #7: Stand up and be counted!
- Step #8: Track progress with a daily burndown chart
- Step #9: Finish when you said you would
- Step #10: Review, reflect, repeat...

'Implementing Scrum' PowerPoint Presentation

10 Key Principles of Agile Software Development

read more