- Burn Down Chart
- Burn Up Chart
- Story Points
- and much more….
In an earlier interview I did with with Steve Denning, we talked about his new book: The Leader’s Guild to Radical Management – which is focused on resolving an old management conundrum:
How do you combine rapid innovation with disciplined execution?
Steve found that an unusually high proportion number of workplaces addressing this conundrum were in software development.
Jeff Sutherland talked recently with Rini van Solingen in Delft, Netherlands, about Scrum and radical management.
You are invited to join us online June 8-9 for Agile Connect – a virtual conference – where we’ll be streaming live from Agile Development Practices West in Las Vegas!
Choose from keynotes and technical sessions, interact with your colleagues and speakers, watch live speaker interviews from the EXPO floor, and more! For your convenience, sessions will also be available on demand after the event. Register today and forward this invitation to your team for your complimentary passes to this event.
Register now and get your free pass to Agile Connect, or view the full view the full program details.
In this Video interview, Craig Larman discusses the many challenges you face when scaling scrum to large organizations at the recent QCON conference.
These challenges stem from decisions to use component teams over feature teams; adopting out sourcing without careful consideration for the impact of that decision; and over specialization of skills and limited learning which leads to waste, bottlenecks, and poor performance.
Tuesday, May 3-4, 2011 (Vienna, VA)
Learn Agile and Scrum, and how to apply them to your workplace (earn 15 PDUs)
This workshop will help your agile and Scrum transformation efforts stick!
WHAT YOU WILL LEARN:
- Real world Agile and Scrum practices
- How to apply Agile to your workplace.
- How to roll out Agile with minimal risk and the highest chance of success
- Secrets about moving to Agile such as how to mix your existing practices with Agile practices.
- How to Become Agile within common constraints such as distributed teams, governance, and fixed bid work.
- Strategies for overcoming organizational and team level impediments to agile transformation.
- Best practices for sustaining agile and Scrum as your business and environment change.
Scott Dunn is offering his PAY IT FORWARD Certified ScrumMaster training course again. It is spread across two Saturdays and delivered as a give-back to the community.
- The course is Free for those currently in transition, working for a non-profit, or as a thank you for a donation of any amount to one of several non-profits at the training.
- $50 fee for Scrum Alliance membership and certification.
LOCATION: Graciously hosted by Vineyard Christian Fellowship, 5340 E. La Palma, Anaheim, CA.
How it works:
Register via the link below, which requires a $50 fee, which is the Scrum Alliance fee for membership and certification.
- If you are currently out of work, that’s all that is expected. And out of work means loss of and looking for full time work. This is not for contractors in between gigs. Scott will ask for proof of unemployment status. This class is me paying it forward for the opportunities I have been given.
- If you work for a non-profit, that’s all that is expected. Scott will ask for proof of employment with a nonprofit. This class is to gift to you for the work you do.
- If you are currently employed, you will have the opportunity to donate to charities that will be presented at the training. The class and certification are a gift to you for a donation of $200 or more to any of the charities presented. Scott will cover the details of how to make the donations at the training. That is you pay it forward to benefit others. If you decide not to donate, the $50 will be used to cover class material costs and a gift back to the host (Vineyard).
* * * * * * * * * * * *
Like what you read? Get hot news on the Agile-Lean community, upcoming webinars, case studies and tools you can use to help you be as Lean-Agile as possible….delivered right to your inbox weekly. No spam or junk mail. You can unsubscribe at any time.
Life used to be simpler. In the 90s, if you wanted to go Agile, XP was the route of choice. And then Scrum became popular. And it was not too long before organizations began to hit the limits of these approaches due to their focus on teams. And then it became apparent that lean principles could be applied to software and Lean Software Development and later Kanban were added to the mix. Now, if you want to go Agile, you have a great many choices: Not just about which method to use, but where to start, whether to go top-down or bottom-up, and what should be the scope of your effort.
It can be daunting. Let’s see if we can make it less so.
WHAT IS AGILE?
Let’s start by considering what is meant by “Agile.” Many people would tell you that Agile means building software in small steps (iterations), measuring the progress and health of the project in terms of developed software, and working in close contact with the customer to ensure that what is built is truly useful. This is what I would call “team agility” because its focus is on the team and how the team works. It is the most common form of agility in use at present. While it is very effective for many, it should not really be the goal you strive for.
The best measure of success – the real goal of our work – must focus on how responsive the business unit that the development organization serves can be. I call this “business agility.” It encompasses more than merely the team. Unfortunately, it is much harder to achieve. Business agility is the ability for a business (or business unit) to deliver increments of business value to their customers (for product companies) or the business side of the organization (for IT organizations). Business agility enables companies to respond quickly as needed when market conditions change, new technologies arise, or new ideas are developed.
Business agility is like having a car that is nimble, efficient, and goes where it needs to. Team agility is like having a finely tuned engine that enables the car to do whatever the driver wants. In other words, business agility is the real goal; team agility is a means to that end. Now it may be that in small enough organizations, focusing on the team alone may be adequate; however, in most organizations of size, trying to achieve business agility by focusing on the team is like trying to get a better performing car just by tuning and re-tuning the engine: it can help but you might see better results by improving the transmission or brakes.
POPULAR AGILE METHODS: SCRUM and XP
As I said, Scrum and now, to a lesser extent, eXtreme Programming, have been the most popular methods in the Agile movement. XP is rooted in development practices such as pair-programming, test-first, continuous integration, collective ownership and more. Scrum is primarily a process framework that exposes an organization’s impediments. Its underlying assumption is that if you can see what you are doing wrong, you can fix the problem. Scrum’s power is that you will discover problems quickly – in a matter of weeks. This is a vast improvement over waterfall methods. The challenge is that sometimes the problems that are exposed are such that the solutions are not clear.
Both methods use iterations (building in 1-4 week intervals) and self-organizing, cross-functional teams.
Scrum has gotten to be more popular for a few reasons. First, it is easier to start because the team doesn’t have to commit to the technical practices that are the core of XP. This level of change is too much for some teams to bear. Second, Scrum’s certification program has spawned scores of “Certified Scrum Trainers” (CSTs) who both teach Scrum and promote it. As a result, many in the industry have come to think that “going Agile” means “taking a CSM (Certified ScrumMaster) class and adopting Scrum.”
CHALLENGES IN THE AGILE WORLD
Scrum has grown virally. Now, the challenges are showing up. In fact, one of the originators of Scrum, Ken Schwaber, said in an interview with Agile Collab that
“75% of organizations using Scrum will not succeed in getting the benefits that they hope for from it.” 
There are many opinions about why this is the case. This article’s author posited several reasons including,
- Many problems facing development teams actually originate outside the team; for example, overloading teams by giving them too many projects at one time.
- Many large organizations have poor deployment methods that make it difficult to get software out the door. While Scrum may expose these impediments, they are difficult to solve and Scrum, in itself, does not give any insights on how to solve them.
- Many organizations have difficulty creating the cross-functional teams that Scrum requires to work. People with specialized skills, knowledge of legacy code or domain expertise are often required to be shared across teams, breaking the power of the Scrum model.
- Many teams that are new to Scrum have never been taught the principles of product development flow.
- While Scrum was originally designed for co-located teams, it is often necessary to use distributed teams.
Many Scrum aficionados claim that the real reason that organizations are not experiencing success with Scrum is that those organizations just don’t have the discipline or motivation necessary to solve their problems.
Regardless of the cause, the problem remains. To meet this challenge, two other Agile-related methods have sprung up: Lean Software Development and “A Virtual Kanban System for Software Engineering” (or ‘Kanban’ for short). Both of these methods directly address the problems that organizations are having with Scrum. It is why I started doing Lean over five years ago and Kanban about 3 years ago.
LEAN SOFTWARE DEVELOPMENT
Lean Software Development is founded on the understanding that the principles of Lean manufacturing and product development methods can apply to software development. Of course, the practices are different but the mindset, the way of thinking, is the same.
Its origins date back to the mid-90s with an article by Bob Charette. It became popularized with by Mary and Tom Poppendieck’s books, the first one, Lean Software Development, An Agile Toolkit, being published in 2003 (Poppendieck & Poppendieck, 2003). Lean Software Development is based on the notions of eliminating waste (any effort that is not of value to the customer), optimizing the whole (going from “concept to cash”), delivering fast, building quality in, respecting people, improving relentlessly and deferring commitment until you know what you need to do.
A second camp, so to speak, has sprung up around the work of Don Reinertsen. Reinertsen approaches Lean on the basis of appreciating the system that people are working in, fostering the skills of the people you have in that systems, and attending to time by seeing how work flows through the system. By “flow,” he means to see where delays occur or where large queues form.
Regardless of which way you prefer to approach Lean, it is useful to provide insights into how to solve problems both inside and outside of the development organization. Its model of flow (focusing on fewer, smaller things in your development pipeline to get value delivered quickly) suggests that one way to improve your software development value stream is to avoid overloading your development teams. When you consider how many development teams seem to thrash because they are doing too many things at once, you may intuitively get this concept.
Kanban is based both on Lean and the theory of constraints. It was created by David Anderson about five years ago and is achieving an upsurge in interest. Kanban is based on a few basic premises. The first is that requiring an organization to undergo a large change at one time in order to start being Agile may be counter-productive. Telling people they have to adopt new roles and work in a different way often creates fear in those being forced to change. They feel devalued as they are told their former methods of working are to be abandoned.
The first few years of the Agile movement saw Scrum adopted where teams already existed and the developers/testers/analysts wanted to change. Many going the Agile route no longer fit into this class – perhaps another reason for the difficulties encountered.
Many Agilists will tell you that the way to overcome this high amount of change is to hire a trainer and coach. However, an alternative approach may be to understake a smooth transition while starting down a road that gets you to your ultimate goal in a less disruptive manner.
The essence of Kanban is to start where you are and do three things:
- Make agreements with your stakeholders as to what your goals are and how many projects the developers will be working on at any one time.
- Create visibility into the development process by mapping its value stream. A “value stream” is the series of steps where an idea goes from concept to being defined to being built to being deployed to being used. Then have explicitly defined policies of how work moves through the value stream. This is extremely important because it enables management to see how their actions affect the team and because the discussions around these explicit policies greatly accelerate learning.
- Manage the amount of work in progress (WIP) being done at each step. In particular, the team (and management) needs to look for places where the work gets backed up and then figure out how to unblock things. This clarity provides insights into solving the impediments the team hits.
Corey Ladas incorporated Kanban to the Scrum framework to create a hybrid called “Scrumban.” This has been a useful method for helping Scrum teams to adopt Kanban methods.
ACHIEVING BUSINESS AGILITY: WHERE TO START
So, where do you start? It depends on where you are and where you want to go. My experience is that trying to start an Agile adoption through a team pilot project is not always best. Like that car’s engine, the team method may not be the problem. Even if it needs improving, you will always be better off by looking at the entire context within which software development is done and then choosing what to improve. Here are two recommendations:
- Begin by looking at the entire value stream. Where are the challenges, what needs to improve? This does not mean you are committing to changing more than the team, but doing so will provide insights that will ensure team progress translates to business progress, to business agility.
- Let the teams involved choose between Scrum and Kanban. They will intuitively know which is best for them. Part of respecting people means to allow them to choose how they do their work – within the context of the business, of course.
Considering the entire context is the difference between scaling agility and agility at scale. But that is a topic for another article.
AUTHOR: Alan Shalloway, CEO of NetObjectives. If you are interested in learning more about Kanban, Lean, Scrum, or XP, please visit the Net Objectives resources page at http://www.netobjectives.com/resources. You can also find a wealth of information on Lean and Kanban, as well as upcoming conferences, at http://www.leanssc.org and http://www.kanban101.com.
– Anderson, D. (2010). Kanban. Sequim, WA: Blue Hole Press .
– Ladas, C. (2009). Scrumban: Essays on Kanban Systems for Lean Software Development. Modus Cooperandi Press .
– Poppendieck, M., & Poppendieck, T. (2003). Lean Software Development: An Agile Toolkit. Addison-Wesley Professoinal.
– Reinertsen, D. (1997). Managing the design factory : a product developer’s toolkit. New York: Free Press.
* * * * * * * * * * * *
Like what you read? Get hot news on the Agile-Lean community, upcoming webinars, case studies and tools you can use to help you be as Agile-Lean as possible….delivered right to your inbox weekly. No spam or junk mail. You can unsubscribe at any time.
Kanban is the next generation of Agile methods, built on a lean foundation. This method is now applied to knowledge work such as software development — domains in which “inventory” isn’t visible but its effect is still felt. If your organization struggles with the inventory of unfinished work, bugs and other quality issues, while you are under pressure to deliver faster and more frequently, you may benefit from applying the Kanban method.
Kanban is based on Lean Product Development flow and provides insights into how to solve many software development challenges while being inclusive of management. It can be implemented at a pace of the development organization’s choosing. making it much more flexible than other agile systems. Kanban is meant to be adapted to the particular needs of each organization.
- Part 1: USING KANBAN TO IMPROVE SCRUM
- Part 2: KANBAN
- Part 3: ADVANCED SCRUM AND KANBAN
WHERE: Anaheim, California
WHEN: 2 Saturdays (1/15 and 1/22 from 8-5pm)
Class Size Limit: 20 (Minimum 0)
This two-day ScrumMaster certification course taught by Scrum Alliance Certified Scrum Trainers provides everything you need to get started with Scrum. One of the largest and fastest-growing Agile project management frameworks, Scrum is a simple software management technique that has a small set of interrelated practices and rules, is not overly prescriptive and is able to produce productivity gains for software development teams almost immediately.
This course shares time-tested practices for managing product backlogs, planning your releases and iterations (Sprints) and tracking and reporting progress. You’ll learn how to plan and run Sprint Planning Meetings, daily Scrum Meetings, Sprint Reviews, Sprint Retrospectives and more!
Currently, an individual is certified when he or she has attended a Certified ScrumMaster course and has completed the exam.
On completion and passing of the exam, participants are registered as Certified ScrumMasters (CSMs), which includes a two-year membership in the Scrum Alliance, (www.scrumalliance.org) where valuable ScrumMaster-material and information are available exclusively to CSMs.
For more information, go to http://www.scrumalliance.org/scrum_certification
- Introduction to Agile Principles
- Introduction to Scrum Principles
- Scrum Core Elements & Practices
- Product Visioning
- Roles & Responsibilities
- Product Backlog & Release Planning
- Sprint Backlog & Sprint Planning
- Daily Standup Meeting
- Burndown Charts & Project Reporting
- Sprint Review & Retrospective
- The 59 Minute Scrum
Participants of this course will be eligible to apply for 14 PDU’s toward their continuing education requirements with the PMI (Program Management Institute)
Cost: $50 per attendee.
- Why split stories?
- Why will this make the team go faster?
- Why is splitting stories by architectural component bad?
- What is a better way of splitting user stories?
We will start with a quick review of what user stories are and then learn why large stories often limit your team’s progress. Then we will learn how to split them. Along with some examples in the presentation you’re invited to come prepared with your own user stories and we will see if we can help you split a few on the fly.