The Scrum methodology of agile software development marks a dramatic departure from waterfall management. In fact, Scrum and other agile processes were inspired by its shortcomings. The Scrum methodology emphasizes communication and collaboration, functioning software, and the flexibility to adapt to emerging business realities — all attributes that suffer in the rigidly ordered waterfall paradigm.
Posted by MJ under Uncategorized
Many Scrum classes do not include preparation activities and include only minimal measurement and feedback about a participant’s Scrum/Agile understanding. MJ’s 3.1-day Scrum workshop is intended for people looking for something more: more interactive exercises, more knowledge measurement and feedback, and more examples of how Scrum and Agile are used in the real world.
The .1 is the required online preparation. Fortunately this is the most entertaining online resource currently available: The Scrum Training Series. Since all participants show up with this baseline understanding, we’re able to do more advanced activities than a typical CSM class would allow. This is the class we wish we had gotten when we started doing Scrum.
Posted by MJ under UncategorizedTags:
For more on this unbelievable story – click on the video from CBS below.
One of the things I am thinking about and working on is the concept of being more available.
It’s New Years Eve and personal and professional transformation seem to be top of mind for most everyone around this time a la (a) goal setting exercises and (b) the obligatory New Years resolutions.
I wanted to offer two different takes on transformation, one is a bottom up and one is top down. In the bottom up interview the #1 blogger in the world talks about how to make incremental changes through experimentation when you don’t have the authority to change the entire system. In the top-down interview we hear from a professional CIO how to transform a failing business to be more data driven and innovative.
The first take on transformation is from Seth Godin, the #1 blogger in the world. Here’s Seth Godin’s interview on transformation. Have a watch. Do you agree or is this characterization oversimplified?
Next – have a watch of Uber-CIO Randy Mott. Randy Mott was the CIO of Wal-Mart, Dell as well as HP and is now CIO of GM). In this interview with Information Week where he talks through his transformation playbook:
*Data Driven Decisions
*The Speed Merchant – bringing cycle times down
*Efficiency vs. Effectiveness
*How to move money around to be more around innovation and less around keeping the lights on
He will be in-housing over 8,000 IT jobs to innovation centers to hot tech markets like Austin, Texas or Silicon Valley.
Do you agree with Randy or Seth? What are your guiding goals in 2013? Looking forward to reading your comments.
Tags: agile, interview, transformation
Building and maintaining a Product Backlog can be a time-consuming effort. Though the Product Owner has final say in the prioritization, a good product backlog is a result of a combined effort of the entire team – Product Owner, Scrum team, ScrumMaster and stakeholders.
One expert in this area is CollabNet Certified Scrum Trainer Angela Druckman. Ms. Druckman will be hosting a webinar focusing on techniques and ideas for improving the overall effectiveness of backlog management.
The webinar will be held on Monday October 27, 2011 at 11:00 am pacific time. You can register here: https://www1.gotomeeting.com/register/568237585Tags:
Posted by admin under Uncategorized
How can large enterprises become more agile? Many people think that the common obstacles to agility in large organizations are due to “giantism” and are entirely unavoidable. In other words, it’s like trying to maneuver the Titanic around the iceberg. Many people within the large organization will resist the change saying, “too much to do” or “not enough resources”. However, these are often misconceptions that reinforce bad habits and contribute to change resistance. In a recent article posted on gantthead.com called “Obstacles to Enterprise Agility”, Michael James, a CollabNet Certified Scrum Trainer outlines some of the key impediments to enterprise agility which include:
- Naïve Resource Management
- Organizing teams by functional specialization
- Organizing teams by architectural components
- Rampant technical debt
- Lack of commitment to transformation
Are you working on an agile transformation? Do these sound like topics that have been on your mind lately? If so, I encourage you to check out Michael’s article here.Tags: agile, impediments to enterprise agility, obstacles to agility, Scrum Basics, scrum impediments
I recently attended a webinar hosted by Scrum company Danube Technologies. The session, called “Definition of Done: An Organizational Perspective,” was led by Dr. Dan Rawsthorne, PhD, one of Danube’s Certified Scrum Trainers. Over the course of an hour, Rawsthorne discussed creating and revising acceptance criteria for various kinds of user stories and how those stories can be used as standardized templates as well as an educational tool within a Scrum organization. In all, it was a great webinar; Rawsthorne clearly speaks from years of experience.
Sound like something you, your team, or your company could benefit from? Check out the entire list of special event webinars offered by Danube. They’re free and always hosted by a Certified Scrum Trainer. There’s a chunk of time at the end reserved for questions and, importantly, there’s no sales pitch. Highly recommended.Tags:
Posted by admin under Uncategorized
Lately, our discussions here have focused on scaling Scrum for the enterprise. That is, we’ve been thinking bigger and moving away from some of the fundamental issues pertaining to Scrum and team dynamics. But a reader request reminded me that not everyone is focusing on translating the benefits of small team Scrum for the largest, most complex development environments. So let’s get back to the basics and consider a more introductory topic: the Product Backlog Item.
The Product Backlog Item (or “PBI,” “Backlog Item,” or sometimes simply “Item”) represents all the work a team needs to complete. However, since Scrum utilizes an incremental and iterative approach to development, only a handful of these PBIs are tackled by the team in a given sprint.
Because it is the primary responsibility of the Product Owner to determine what work will yield the most business value, it is also his or her duty to prioritize the PBIs. That is, each sprint, the Product Owner determines which PBIs a team will attempt to complete within the sprint. This is often referred to as the Product Owner dictating the “what” (i.e. what is to be delivered by the end of the sprint), while the “how” is left for the team to decide. That is, the team decides “how” to complete its PBIs—in what order, which team members will work on specific Items, etc.
During the sprint, Tasks are defined for each PBI, so that the Team has a clear sense of how it will accomplish its work. It is important to note that the Product Owner should not be monitoring their progress at the Task level. Rather, Tasks are simply more granular versions of the work entailed to complete a PBI. As such, they are created for the benefit of the team—both in terms of sizing up their PBIs in a realistic manner and ensuring the Team knows what everyone is doing to complete Sprint goals.
It is important to note that PBIs are estimated using Story Points—i.e. abstracted estimates of difficulty—whereas Tasks are estimated with hours. Since these two forms of estimation are completely unrelated, PBIs and Tasks should not be compared; they are separate entities.
As a best practice, PBIs should always be estimated using a consistent scale of Story Points. These points can be anything—factors of two, t-shirt sizes, dog breeds, headaches, etc.—but what is important is for the team to agree upon their scale, the approximate values of each estimate within the scale, and use them consistently.
Tasks, on the other hand, should employ hour estimates. Most developers are comfortable estimating the number of hours they believe it will require to complete a given Task. However, some advanced Scrum teams prefer not to assign hour estimates to their Tasks. Instead, they simply mark their Tasks as “done” or “not done,” which means the corresponding report would track Tasks remaining, rather than hours. In ScrumWorks Pro, all meaningful, long-term metrics rely on PBI estimates, not those associated with Tasks.
Tags: Product Backlog Items, Scrum Basics, Tasks
Posted by admin under Uncategorized
As Scrum continues to grow in popularity, one of the hottest topics on the minds of the community is how to translate the benefits of a paradigm created for small, collocated teams for enterprise-level installations of hundreds, if not thousands of users. Given that communication channels increase (and therefore communication decreases) as the size of a team grows, this issue is only compounded when teams begin to scale to Scrum-of-Scrum configurations. Clearly, the solution is a tool designed specifically for Scrum projects that can allow teams to remain small, but nonetheless connected to the bigger picture.
Of course, the tool also needs to be flexible enough to meet the unique demands of large and complex development environments. For example, large organizations often develop products with shared components, which require the ability to plan releases against multiple backlogs. And while Scrum and other agile management methods have steadily crept into the software development landscape, the project management tools available have not kept pace.
But all that may be changing now. I just watched a screencast of ScrumWorks Pro 4 (you can watch it, too, here: http://danube.com/sw_flash/release-4/) and this release’s new functionality makes it the first truly enterprise-ready Scrum tool. Namely, it addresses the issue outlined above by allowing customers to manage high-level features and releases that span multiple product backlogs. This is a really important breakthrough. Before that functionality existed, organizations had to creatively develop workarounds for their agile tools to achieve the same effect, but, still, with less-than-ideal results. Now, products can be associated with multiple programs, which, in turn, allows shared components to be modeled accurately while providing organizations with a more realistic view of overall progress. This is going to eliminate some very big headaches for some very big companies… You can read more about it here.Tags: program management, project management, Scrum Basics, Scrum tool, ScrumWorks Pro
Scrum Training Series
- Do you REALLY want to learn Scrum? Try a 3.1-day CSM class with case studies. July 25, 2013
- Scrum based funding model – 20 percent May 9, 2013
- MJは６月と７月の２ヶ月間、日本に滞在する予定です。スクラムのコーチングまたはトレーニングに興味のある方は是非ご連絡ください。 March 14, 2013
- The Next Big Idea March 5, 2013
- On Being Available February 17, 2013