July 11, 2014

All Posts Tagged With: scrum

Agile Coaching Blog

The Release Plan: The Who, What, When, Why and How

The release plan is the team’s current understanding of what features are going into the next release of software, how many effective developers are deployed on it, and the current status of the development effort. But how do you go about planning that release, especially if you don’t know your velocity?

In this video I’ll cover how a team plans a release based on a groomed backlog and come up with an initial velocity of the first sprint. How it works and the results of each sprint will update how the plan is published and moved forward in subsequent sprints. I’ll walk you through the steps on how to plan an entire release.

Want actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.

subscribe

Share:

All About Agile: Giora Morein’s Interview with Money For Lunch

Earlier this month, I was interviewed by internet radio show, Money for Lunch. The program introduces leaders, authors and innovators to a business-minded audience focused on business and financial news. I spoke with Bert Martinez regarding the topic of agile. We went over some of the basics, such as:

  • What is agile and Scrum?
  • What are the common pitfalls of agile or anti-patterns an organization might see?
  • How does BigVisible avoid the pushback and get organizations to successfully adopt agile?

I speak to the topic of agile as a fundamental shift in how large organizations view the delivery of products and projects – going from big batch, long-phased delivery cycles to something iterative and incremental – quickly bringing products to market.

It’s easy for organizations to become bogged down in their own processes and systems. But more and more, organizations are widely adopting and scaling agile to be more responsive, to increase quality and achieve more successful outcomes because the market is demanding it. Buyers are more knowledgeable and know what they’re looking for and they demand better product in shorter timeframes. If organizations can’t deliver, they won’t be able to remain competitive.

You can listen to the full interview here.

Want actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.

subscribe

Share:

Agile Changed Their Lives…From The Trenches of a CSM Training Class

As a long-time agile coach and trainer, I have had the privilege of teaching many types of agile courses, but more recently, I’ve been focusing on Scrum certification training for BigVisible. I teach certification classes available to the public, as well as private engagements with our customer organizations. Not too long ago, a request came in from a PMI Chapter, looking for a three-day class that teaches the fundamentals of Scrum to become a Certified ScrumMaster and prepares project leaders for the PMI-ACP exam.

Along with the usual challenges of a three-day class (longer days, more materials, additional preparation) another potential challenge began to reveal itself. This class was on the larger side (30 attendees) and made up of an audience of seasoned project management professionals well-versed in traditional/waterfall project management and not very familiar with agile methodologies. What I did know was that there was a thirst for more Scrum knowledge in general, not just preparing for the PMI-ACP exam. But that still didn’t calm my apprehension. Past experience had shown me that project managers tended to be a tough crowd. I mean, after all, these folks were seasoned PMs who have been doing their job for many years and doing it successfully. Now, they’re being asked to take a different approach and manage projects in a new manner.

One of the many things we do well at BigVisible as part of our class experience is not to sell people on agile, but to get participants to learn from one another, share their experiences and have valuable discussions with one another. We use hands-on exercises and interactive simulations throughout class to teach agile principles. This helps people feel more at ease with the concepts and feel confident in a safe environment that they can apply their knowledge and feel prepared to take on a Scrum project. That’s not to say they’ve becomes experts, but they’re more prepared with the tools and knowledge to take on projects in an agile fashion.

As our class kicked off and we moved through the exercises, there was an arsenal of questions, including “how does this work in the real world?” or “how is this different from what I’ve done the last 15 years?” Even with all the materials I had and the planned simulations, I still needed to make it real for them. I shared my past work experiences at previous organizations. I was able to articulate the benefits of agility, such as: reducing risk, quicker delivery of product, higher quality and more satisfied customers. Collectively, the group shared lots of their own stories, tapping into their own experiences of success and failures of past projects. The dialogue was rolling.

As this sharing continued over the three-day period, you could clearly see this group morph from being skeptics to advocates. They began to shift their thinking from “this will never work” to “how do we make this work in our own environments”. They were truly interested and engaged and the deep discussions continued. Then another wonderful thing happened. This group was so intent on learning, applying techniques to exercises and figuring out how to make agile work for their organizations – they really began to bond. It was such a strong bond for such a large group – but they became a community, a support system.

They wanted to have access to this support system and continue their discussions outside of the class. A good handful of people from the class approached me about creating an online community for them. I told them about our Training Alumni LinkedIn group – but they wanted one specifically for them. One of the participants created a LinkedIn group just for them and EVERYONE opted in to participate. Surprisingly, it’s been a long-lasting, active and collaborative community. They still share successes, praise each other when someone gets certified, share experiences, and initiate discussions.

As we wrapped up the class, what happened next will be something I’ll never forget. In addition to providing complimentary feedback about the course through our feedback forms, a several people individually took time to approach me. For each of them, this class became a game-changer for them; that it actually changed their lives.

Taken aback, I asked them what prompted their comments. As experienced PMs, they were starting to feel that their skills and approach were not as valid or valued as much anymore. To them, their new knowledge would open doors to new opportunities or new ways of succeeding in the current roles. The class put them in a mindset that felt like a new beginning for them, a breath of fresh air. The world was changing around them and they now felt like they could adapt and change with it.

What I thought was going to be a challenging three days turned into a very rewarding and fulfilling experience. This was a group that clearly got out of what they put into the experience.

For this group it was about the people, the dialogue and interactions. What’s been the agile game changer for you?

Want actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.

subscribe

Share:

The Role of Scrum Master – A Permanent Position?

As agile frameworks grow in both popularity and widespread use, especially with Scrum leading the way, Scrum Masters have grown in popularity with companies, and we see an increase in job postings specifically for them. However, we have to understand that “being” an SM is not a position to occupy, it’s living up to a set of responsibilities.

Although the role itself is an artifact of Scrum, the responsibilities of the role are nothing new for a healthy team environment. A Scrum Master needs to support the team’s ability to focus on what is important and deliver on commitments.
team leadership
When organizations implement agile frameworks, a Scrum Master role is needed to help teams re-learn the discipline of healthy delivery. But as time goes by, the responsibilities need to be absorbed by the entire team. There may be one person that takes a lead, but the mantle lies on the entire team’s shoulders, and the position of Scrum Master slowly phases out as a new team capability emerges: leadership.

Leadership at the team level is something we have slowly diverged from in the name of organizational efficiency over the last few decades. Management theory has taught us that the most efficient way of managing the work is to remove tasks and responsibilities outside of each person’s job description. So developers should only do development, QA only testing, etc. Leadership is seen more in terms of a craftsman expertise with a focus on tightly controlling the work itself.

I don’t know if “Scrum Master-ing” is a professional endeavor for a life-long career or more of a step along the way. I think that the more you practice it, the more you really dive into becoming a change agent. The responsibilities of the role lend themselves naturally to that progression. For instance, the more teams you lead as a Scrum Master, the more you learn to read the patterns of impediments, and the more you will seek to prevent/mitigate the formation of problems you have observed in the past. Why wait until challenges materialize when we can go out and influence the outcome early, right? And you would do that by influencing the environment in which the patterns are forming to help “change” the circumstances that are developing. Now, you’re now thinking like a change agent.

Like a good leader, a Scrum Master builds a legacy for the team to perpetuate once the position is no longer needed. And now the role persists through the team.

Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.

subscribe

Share:

What Big User Stories Could be Telling You

User stories are intended to be a high level description of some functionality. It is, however, common to find user stories growing into specs or large use cases that resemble whatever the organization used to do, back when they did large requirements documents. Comments like “The stories are not detailed enough to start development” or “This took much longer than expected so we should have more acceptance criteria for next time” can become common. There is a balance here that we should watch and adjust carefully. And most of the time we think the solution is more story documentation.

Here is the story card AND all the acceptance criteria, wire frames, specs, use cases, test plans, flow diagrams, architecture...

Why User Stories Get Big

I like user stories as an easy to understand idea for a company to start thinking about a light weight way to communicate needs, features and benefits. It is hard to describe in brief sentences all the forces that pull organizations to keep them thinking in lots of details. A few might be:

  • A culture and history of Big Design Up Front that makes it hard for feature definition to happen just in time.
  • A continued need for long range planning requiring estimates for work that will possibly take months before it actually starts.
  • Skilled technical people who are accustomed to talking about technical details instead of the needs of the user.
  • And more…

Lack of Focus

The most powerful and subtle force to cause “user stories” to grow is a continued lack of focus for the people defining features and those creating the features.

For example, if I am Product Owner of 5-12 products working with 3 teams who are all working on multiple products, I am not able to think of a feature, collaborate on it’s definition as it is built, see it created and then think about the next feature. I have to document my thinking of every feature because one hour from now I have to think about other features that also might not be built right away.

The key to being truly Agile is to finish stuff. The more inventory of ideas, features, undeployed code, etc. that we have, the less Agile we can be.

Have Conversations

In short, Ron Jeffries, the inventor of User Stories, said that the user story should have “3Cs” of attributes: Card (small enough to fit on an index card), Conversation (is a place holder for conversation) and Confirmation (a definition of when we are done, such as acceptance criteria). Most of the symptoms prevalent when stories grow big are likely indicators that the Conversations are not taking place and people are writing stuff down in an attempt to fill the gap.

Don’t write more stuff down. Figure out why the right conversations are not happening. i.e. “Individuals and interactions over processes and tools.” That said, sometimes what we see as an over-documented abuse of the user story is a vast improvement on what the organization used to do. We have to temper our zeal with a dose of client reality as we work to get incrementally better.

Do you see user stories getting too big? If you don’t use user stories, does what you use help or hinder conversations? What is your balance between the ability to deliver vs. the need to document thinking?

Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.

subscribe

Share:

Scrum Meeting Success for Distributed Teams

In a previous blog, I discussed ways to make distributed daily scrum meetings more effective. This blog reinforces those ideas and provides additional tips to run successful scrum meetings with geographically distributed teams.

Productive, timely, 15-minute Daily Scrum meetings, remain a challenge. As many practitioners will attest, co-located Daily Scrum meetings are nearly as challenging for some of the same reasons:
- Meetings go beyond 15 minutes
- Not everyone has a chance to be heard
- Conversations wander into resolutions and opinion
- Impediments are not captured and addressed
- Others interrupt
And more…

Holding team meetings where members are not in the same physical or mental space is quite challenging, and it becomes more so when the team is geographically distributed. As I mentioned previously, the initial rule of thumb was to breakdown the daily meeting into small deliverables and then focus on each part of the meeting. The overall Definition of Done is the teams take ownership of the Daily Scrum meeting and use this as a foundation/basis. This idea has evolved into a goal for Daily Scrum meetings of having the team take ownership and management of their daily meeting. With this, we can create “Definitions of Done” for each part of the meeting.

For example:
Part 1: The team listens to each other’s ‘questions 3’ with no interruptions.
- Definition of Done: each team member has an equal voice to state their answers and be heard by their team members.

Part 2: The ScrumMaster reads the impediments/issues they recorded and the team adds, corrects and confirms the list is correct
- Definition of Done: the ScrumMaster reads off the impediments and has the team approve them

Part 3: The participants in the Daily Scrum meeting organize additional conversations around the Sprint and the results of the Daily Scrum Meeting the team.
- Definition of Done: the team members self-organize and work on the issues at hand and have these groups communicate what they did before the next scrum meeting, to the rest of the team.

When it comes to implementation there‘s a way to execute this process. For example:.
The meeting begins with one team member (initially the ScrumMaster) asking a team member the ‘questions 3’.
- The team member identifies the task and the story they are working on. They describe at a high level what they are doing and how much more time they need to finish.
- The team member then describes what they plan on doing tomorrow. If they will be moving to a new task, they should state which task.
- The team member then states what issues/impediments/ concerns they have about getting the work done or completing the sprint..
- Team member #1 then asks another team member the ‘questions 3’. This is a sure way to transfer ownership of the meeting to the team.

This is not a ritual. It is a basic pattern of action that can be used to start off a new team, orient new team members and get a team back into a rhythm. I have found that getting back on track is a lot easier if there is a simple base or foundation to structure and define roles. From there, teams can quickly self-organize…and it works well when things get stressful!

Roles and Actions for the Daily Scrum
ScrumMasters don’t run the Daily Scrum – they guide the team to run it themselves. Their primary focus is to collect the impediment list and get it approved by the Team. There should be a task on the task board regarding impediments for reporting the status of impediments.

Team Members individually and collectively run the meeting.

The Product Owner should be there listening and ready to answer questions immediately after the meeting closes.

Anyone who has committed to deliver something to the team during the Sprint must have a task on the task board and attend and answer the questions 3. This includes Product Owners, stakeholders, and management.

Guidelines and Techniques for the Daily Scrum
1) Turn the meeting ownership over to the team by having each team member ask another member the ‘questions 3’. Since there is no pattern or set order when one team member asks another, people on phones pay attention because they do not know when the questions will come their way.

2) The ScrumMaster is the servant leader, helping the team stay focused on the conversation, the task board, and the questions. It’s surprising how quickly the rest of the team picks up on this focus and brings the more loquacious and “off tangent” teammates back on track by asking “what task are you talking about?” Some teams go as far as including a protocol statement in their team charter stating all questions in the daily Scrum meeting begin with the user story and the task.

3) At the end of the first part of the meeting, the ScrumMaster, who may have been taking notes on the impediments, begins the second portion of the meeting by going over the impediment list to see if any were missed. This action reinforces that this meeting is for the team and that all issues are visible and noted.

4) The third and final part is a call for the issues to be discussed immediately after the meeting. Any team member, including the Product Owner may ask for conversations on story or task issues.

5) As soon as that is sorted out, the ScrumMaster requests that all decisions resulting from the upcoming conversations be communicated before the next daily meeting.

6) The daily meeting is closed and the conversations continue.

Share:

Agile Transformation: Go Faster, But Not for the Reason You Think

A common reason people give for undergoing an agile transformation is that their projects will “go faster.” When most people think of faster they think of getting all the work done sooner. And they are not wrong to think that way. A recent industry survey [PDF] and other sources point to increased productivity as one of the benefits of agile practices. I do not dispute this but I’d like to look at faster from a different perspective. Agile practices pave the road, so to speak. It doesn’t matter how fast your car can go if you are driving on a dirt road.

Pave the Road to Agile Transformation

Magical Agile Transformations?

In this discussion I will focus on Scrum as the framework the team has chosen in order to become agile. Assume a team of good people is formed, trained in Scrum and starts Sprint 1. Suddenly the programmers can write code faster? Or the product owner can define features faster and tests are written and run faster? No, there is no magic. The reality is that most of the individuals on the team are just as fast at their usual tasks as they were before Scrum. Each individual, in fact, is probably not any faster at their specialized skill even after several sprints.

So, given that the individuals on the team are not actually faster, what is happening to make productivity go up? Or does it only look like productivity is up? [Read more...]

Share: