Tag Archives: scrum

Agile from the Trenches – Part 3 – Enabling to a Successful Team

Posted by on September 30, 2010 No comments

I could have titled this post “Agile from the Trenches – Creating a Successful Team”, but I feel that would be misleading and largely an incorrect statement.  A team is initially created by evaluating and assigning members to the team.  But that is essentially where the “creation” part ends, and the “enabling” part should begin.

It is very important that agile teams are cross-functional.  What does this mean?  The team should consist of members with skills in each of the functional areas needed for the project.  For software development projects, this would mean having each of the main functional skills represented on your team: business analysis, quality assurance/testing and development.  Some teams may need additional representation in different areas (architecture, infrastructure, information security, etc.) depending on the scope and complexity of the project.  The goal is to build a team that is as independent and self-reliant as possible.  This will help reduce the risk that outside influences or dependencies on other teams will cause problems.

While the assignment of team members is a very important step, sometimes it is out of our control as leaders and as team members (e.g. a team may already be formed).  It is important that we remember to focus on the other important components of the team building process and focus on enabling the team and what that means.

Team Charter

Before the team can set off and accomplish great things, it is very important that they understand the organizational goals, vision and values as well as those of the team.  During the team building phase,  the team should draft their own charter that will define the teams goals, vision and roles and ensure that they line up with those of the organization.  This will be a living document, and should be updated accordingly as things change.  Here are the key elements of a team charter as outlined by Chris Edmonds (Driving Results Through Culture) in his Most Teambuilding Isn’t post:

  1. Organizational Vision, Purpose and Values – all teams are “sponsored” by the organization in which they operate. A team must understand the vision, purpose, and values of the company so that it can align team purpose and values with those defined organizational elements.
  2. Team Purpose – the team’s purpose statement identifies what the team does, for whom, and why it is important. A clear purpose provides direction for identifying team goals and the roles needed to accomplish those goals.
  3. Team Values and Norms – Values are the enduring principles that guide team and team member plans, decisions, and actions. Norms are the day-to-day ground rules that clarify appropriate behaviors for team members.
  4. Team Goals and Roles – goals identify the measurable outcomes and timelines that must be delivered upon to ensure team success. Roles define the individual responsibilities required for the successful operation of the team.
  5. Team Practices – this section defines the team’s strategies and processes that ensure the team stays on track to deliver promised outcomes. Practices include communication strategies, decision-making authority, and accountability practices.
  6. Team Resources – these are the tangible materials the team needs to accomplish its goals, including time, budget, people, equipment, training, etc.

Chris also mentions that “teams need clarity of purpose, values, goals, and strategy as a foundation for team performance and team member morale.”  This is very important, as a team that doesn’t clearly understand their purpose will be left to wander and their performance and delivery will be compromised as a result.  Each team member should also have clarity of purpose (i.e. what is their role and purpose within the team).  The team members should come out of the team building phase with a clear understanding of their individual role is within the team, and understand the team charter.

Allow the Team to Own the Work

Ownership of one’s work is important.  If an individual or a team do not feel that they are in control, at least in enough control, of their work – then they are also not in control of the outcome and the consequences.  One of the many cool things I like about agile methodologies, is the focus on ownership.  The team should have true ownership over their work, and their commitments from iteration to iteration.  In fact, it is best if the team owns as much of the work as possible.

I will use the Scrum methodology to highlight some areas where the team has power of ownership:

  • Process - Although a team may start by following a predefined process or methodology, they still own the process.  The iterative nature of the process, and the Scrum Retrospective stage,  allow the team to find areas of improvement and make corrections in the process.  This can also be referred to as continuous improvement.
  • Scope – The business will determine and provide the overall direction and priorities of what needs to get done.  This is done through the constant upkeep of the Product Backlog.  During the planning for each iteration, the team controls how much they feel they can accomplish during that iteration.
  • Work Assignment – Rather than having individual tasks assigned, the team is coached to take on their own assignments and manage their own work.  It is important to note that there are controls in place to help with managing accountability in this type of environment (transparency through the board, burndown charts and the daily scrum meeting).  If somebody is falling behind, they are encouraged and coached to reach out to the team.  The basic concept is even though work is typically done at an individual level, the entire team is still responsible of the final outcome.  This encourages the team to work as a team, and not solely as individual high performers.

Enabling and Empowering the Team

We drive down as much ownership to the team as possible so that they are empowered to be productive, innovative and are able react quickly to changes and the needs of the project.  Ownership without proper enabling and empowerment will lead towards frustration and poor performance of the team.  In this type of scenario the team will quickly learn that, while they are expected to deliver, they are not in control of anything to make their lives or the project any better.

Each organization and culture will have it’s limits and comfort level around empowering teams.  This is to be expected and acknowledged.  Ensure the limits are well understood and set expectations with the team so that they understand what, if any, adjustments might be allowed in the future.

Here are some examples, through past experience, where our team has suggested or made changes to improve the project and their work environment:

  • Limiting dependencies on other teams – While the team had been able to deliver on time, a large amount of time was wasted and delivery risk increased, when they had to work with and wait on another team to finish tasks they were dependent on.  It became clear very quickly that this other team was not under the same mandate and timelines as this project; they had delivery requirements of their own.  Organizing and synchronizing the teams may seem like an option (very difficult and risky in my opinion), but the preferred option was to bring in as many of the outlying tasks into our team as possible (thus removing the external dependency altogether).  The team could now control their own outcome and better estimate for future iterations.
  • Automation – Through many iterations and retrospectives, the team has found many places to automate common tasks and processes.  This has increased team productivity, innovation and reduced risk for the project.
  • Process Improvement – The team is continually making minor process and communication adjustments from iteration to iteration.  Continual changes in how work is tracked, how the team estimates and plans has allowed the team to take control and find efficiencies and constantly improve on what they have done before.

A properly empowered and enabled team will naturally start to suggest and make changes which should increase team productivity and overall success of the project.  Some coaching and guidance will be needed along the way, but this is ultimately a much better place to be for the success of any project.

Please share your success stories of team empowerment and improvement by submitting a comment!

Agile and Scrum from the Trenches – Part 2 – Selling Agile

Posted by on May 29, 2010 1 comment

I will be one of the first people to admit that I have a limited exposure to agile methodologies, including Scrum, as I feel I have so much more to learn and experience.  Since we started implementing Scrum a few years ago, and some other agile practices such as Continuous Integration and Test Driven Development, I have become more and more passionate around “agile”.  It just seems to make sense. Trust me, I am nowhere near the agile implementation mastery that I would like to be.  There is still much to be learned…

Team First

It can be disheartening when I see posts online from Scrum teams that absolutely hated the experience and want to go back to Waterfall.  How can that be?  Agreed, Scrum can be a difficult pill to swallow at first when one is very used to the ebb and flow of the waterfall, but I feel the core principles of the Agile Manifesto and the core principles of Scrum should make sense and eventually impassion the team. So why does this not happen?

I believe one of the main reasons this might be happening is because some of us are not doing a good job as Scrum Masters.  We need to do a better job selling agile to the teams (and implementing, but that is for another post).  Selling does not mean shoving down their throats, blinding following the Scrum rules.  It means put yourself in their shoes and see the change from their eyes.  More meetings?  Possibly.  More transparency?  Of course.  More productivity?  Let’s hope so.  Less risk? Definitely.  These are not bad things for the team, but they may not see it that way initially.  It could take months, or longer, for them to “get it”.  Unfortunately, some of them may never “get it”, or may never want to.

Once we understand the changes that are occurring, not just in process, but also in culture, we can do a better job communicating to the team.  Each team member may see things differently, and we should acknowledge that fact and see if we can find a common avenue to help address issues or concerns across the team.

These types of discussions and transition plans could be well beyond the skill level and experience of a new Scrum Master, so in that case a professional agile or Scrum coach may be necessary.

We must not forget that a large part of Scrum and agile is team empowerment, and valuing people over process.  If the team is resisting, then the process probably isn’t working, and may need adjustment.  Use common sense.  I strongly feel that if the Scrum Master protects and empowers the team to the best of their ability, success in a better process in the end should be inevitable.  It may not be Scrum by-the-book, but I think that is perfectly fine.

Selling Leadership

If you are doing Scrum, or another agile process/methodology, hopefully leadership has bought in and is fully committed to going agile.  Perhaps they have not.  Even if they have stated that they are committed, they may not fully understand what it means to go agile.  Helping to form cross-functional empowered teams, providing dedicated Product Owners, and embracing and leading the agile cultural change, are all things that leadership should be doing.

If leadership does not appear to be fully on board, perhaps the benefits of agile are not clear?  Perhaps we need to do a better job selling agile to leadership.  Agile best practices are in their best interest as well.  Motivated, well-equipped, cross-functional teams working on the highest value items to the business at all times?  Reduce waste in process; increase productivity; increase transparency and thus reduce delivery risk.  Who would not want that?  Continuous Integration is an easy sale, in my opinion.  There are no real negatives that could possibly come close to outweighing the automation and reduced waste and risk that would ensue.  Test Driven Development is possibly more difficult to sell, but I am convinced it can be done with supporting arguments and information.

Everything can, and should, be started in moderation.  That also helps reduce the risk of spending time on processes or procedures that may ultimately fail.  It also reduces the risk that team members will be caught up focusing on areas that are not providing the highest value to the business.

With leadership support, agile teams can do so much more.  It is our job to help leadership see the benefits of going agile, and to try to obtain that support.

Selling the Client

I think much of the same arguments above apply to communicating the benefits of agile to clients or our users.  Shorter feedback loops, more transparency, adaptation to change; I see all of these as positives from a client perspective.  There is definitely a lot of adjustment that will probably have to be made (doing small iterations means delivering smaller chucks of features to the client at a time, which is possibly quite different than what they are used to), but there is a reason for this (see adaption to change and shorter feedback loops).

So if a Scrum or agile transition is not going as well as planned, or preparations are being made for a future transition, keep in mind that we must all be good stewards of agile.  We must be able to sell agile, to a certain extent.

After that, it should continue to sell itself.

Waterfall in 30 Day Iterations?

Posted by on September 16, 2009 No comments

This was one of the first thoughts that crossed my mind while I was in Scrum Master training over a year ago.

How can a team accomplish so much (i.e. requirement docs, design, development, qa testing, etc) in 30 day iterations?   It can take weeks to get a large feature just developed, never mind the extra days for testing, extra days for bugs fixes and more time for regression testing.   I thought it would likely take a few sprints together, 60 or more likely 90 days, to fit all that in.

Those were my initial thoughts, both as a senior dev, architect and development manager.  My experience in those roles were telling me, “wow, this is kinda crazy. Kinda cool, but kinda crazy.”  It must work for somebody, otherwise Scrum wouldn’t be so popular, right?  I think so.

It is becoming more obvious over time where we need to make more cultural changes, process changes and further embrace the idea of team empowerment. What would you do if you had to cram all that effort and tasks into 30 days, and still have a production quality product ready at the end of each Sprint?

We are still moving in that direction, and I think we have a clear path so far.   We are automating a lot;  CI builds, soon Unit Tests, and whatever else we can.   Making the code self-testing, self-validating (read TDD for test driven development) appears to be the only feasible way of getting all the development done (and the testing), while maximizing the teams use of the full Sprint (i.e. no “code freeze” to fit in QA testing at the end of the sprint).

The rough part?  How to quickly move toward TDD on a very large, complex application suite that has been under heavy development for many years.  I will follow up shortly with some ideas on how we might address this issue.

Transitioning to the Daily Scrum

Posted by on September 15, 2009 No comments

I am curious what techniques others have used to help their team transition to the Daily Scrum format, as opposed to just going through a normal status meeting (or worse, the scrum master having to prompt each team member to speak up).

Thankfully, our team has transitioned pretty well.  While we are not following Daily Scrum’s to the letter (i.e. we don’t always stand up; always go in the correct order; or require team members to stick money in the pot if they are a few seconds late), we do keep our discussions short (most cases shorter than 10 or 15 minutes.

Early on in the Scrum transition, one of the team members brought in a soft stress ball to the Daily Scrum.  They ended up volunteering to go first and then tossed the ball to somebody else (who inadvertently all eyes were on so they went next).  Since one of those first meetings, that is what the team has done.  They don’t go in order, or sit in the same place, but when they get the ball, they quickly go over the important information:

  • What did I do yesterday
  • What do I plan on doing today
  • What is getting in the way of me getting my work done (Impediments)

Sometimes the team will go into more discussion right then and there when they think it is warranted, but they will keep it short (if it requires more time, they will parking lot the discussion and continue with it after the meeting concludes).  This is the format the team prefers, and it seems to be working really well – so no reason to change it.

One other transitional issue we had early on, was that most team members would look directly at and provide an update only to me (Scrum Master), rather than addressing the entire team.  First Tip:  I listened and gazed around the room, but avoided long-term eye contact with the person speaking.  They tended to start looking at others for eye contact, which is what I wanted.  Second Tip:  Due to other meetings and conflicts, on some days I was unable to make the Daily Scrum (but I was lucky enough to have another trained Scrum Master on the team to help run things).  I think my “not going” helped the team figure out how to update themselves and not worry about just updating me.  I would then always follow up with a few team members to see if anything critical or Impediments were discussed that I needed to be aware of.  Obviously, I still try to make every Daily Scrum that I can – but if I cannot, I feel it is critical that they still meet and talk to each other (as I am just there to facilitate and provide guidance when needed).

I am curious what other Scrum Masters do to encourage their teams to transition to a Daily Scrum rather than a status meeting?

Agile and Scrum from the Trenches – Part 1

Posted by on September 14, 2009 No comments

I work as a development manager for a nicely sized project team (approx 13 team members, including myself).  To be more precise, I am the Scrum Master for the project.

We have not been using Scrum and Agile for a long time.  We are a little more than a year into our transition from waterfall to agile.

The transitional road has not been without its bumps, twists & bends, and occasional detours, but I think we are on the right track and working our way towards a more agile and productive team.

I plan to write a series of short posts to help myself and hopefully others reflect on our mis-steps and successes.  What worked for us may not necessarily work for you;  Nor to I want to give you the false impression that we are completely agile and following Scrum to the letter, because we have some gaps here and there.  Some gaps we are trying to close, and some gaps I am not sure we will even bother to address.  Our ultimate goal is to become more agile with each iteration, and continually find ways to improve our process, improve our team and the product at the same time.

This is tiny snapshot of where the project was more than a year ago:

  • Requirements (what requirements?) were typically conversations or just an email with some description of what somebody wanted.  This was not necessarily a horrible thing, as it allowed the developers, business analyst and project manager/business owner to be creative and discuss the requirements as we went.  However the lack of documentation did cause problems along the way.
  • Our release schedule was our iteration schedule (a release roughly every 3-4 months or so).  A rough plan was devised at the beginning of a release cycle, most of the time.
  • Status meetings.  The team would meet roughly once a week or so, sometimes less frequent, with the project manager to go over each task status.  A lot of unknowns and large tasks resulted in a lot of “I am still working on it” from week to week.

Currently:

  • We are still on a 3 month release cycle (as required by the business), but we work in 30 day iterations (or Sprints).
  • Status meetings went away and replaced with a more natural quick “team discussion” called a Daily Scrum.  Here is where my team deviates a bit from the Scrum rules:  we answer the required 3 statements/questions 1) What did I do yesterday? (or before the meeting) 2) What do I plan on working on today? (or after the meeting) and 3) What impediments are preventing me from getting my work done?  Instead, each team member still goes through all three items, but more freestyle – just normal talking to the team.  Sometimes they take more time and get deeper in the details (rather than parking lot the discussion), but that is a conscious choice the team made, and it does not seem to be disrupting the flow or speed of the Daily Scrum too much.  As the team does not sit in a single room together, this is one of the way they mediate that and have a quick open discussion.
  • Detailed requirements are being drafted, but as Use Cases.  We will likely start moving towards User Stories and using Story Points for estimating the product backlog.  Our BA attempts to focus on Use Cases a sprint ahead of the team, but this is not always the case, and the team will still work together to understand the requirements as they go.
  • Review meetings:  The team demonstrates functionality and what they worked on during the sprint to our Product Owner.  This is a good place to get additional feedback on the overall direction, vision and change requests of the product from the Product Owner – which would make their way into the Product Backlog.
  • Retrospective meetings: Arguably the most important meeting for the team from a cohesive, self-managing, happy and productive team standpoint.  This meeting has gotten noticeably more important, more detailed and more productive as we go.  The team is starting to notice more items that get in the way of them being productive – and are doing a better job in bringing these items up and discussing them with the team.  We try to tackle as many items, at least one, each sprint so we can always feel like we are changing something for the better – and so that the team feels that they are in control.  These discussions also occur at times during the Daily Scrum or anytime during the sprint.  We bring them back up during the retrospective so we can discuss and document it.  Depending on the item, we may try to address it during our sprint (if it is small enough, and makes sense to address it immediately rather than wait, and does not have a negative impact on what the team already committed to).

Both lists a actually much longer, but it should serve as an idea of the progress we are making.  The short of it is I think the team, and the Product Owner, is starting to see a lot of positives from the transition to be more agile.  The team is much more motivated and happy, and the productivity and product quality is continuously improving over time.  There is a lot of ground left to cover, and it may take us a while to get there, but this was definitely the correct direction to take from the fork in the road.

I will follow up with more stories, and links to useful articles and sites that I found to be helpful.