Category archive

Agile Engineering - page 3

Put It On The Team

in Agile/Agile Engineering/Project Management/Teams by

Do you want to have more effective daily stand-ups? Do you want to have the planning meetings flow better and increase the value of these meetings? Do you want to see continuous improvement flow from your retrospectives?

If your answer is yes, then put it on the Team.

I’ve written about trust, relying on strengths, and improving self-organization many times — and the message of these can all be summed up as putting it on the Team. Make the team responsible for solving problems, make the team responsible for defining how to deliver, and making the team accountable for delivery. Most of the times when we talk about the concept of the Team self-organizing, is it more focused on the “how” part of delivery, and not the process. However, remember that the meetings (or ceremonies as some call them) are primarily for the team. Specifically, the Iteration Planning, Daily Standup (or Daily Scrum), and the Retrospective meetings — these are for the team, not the stakeholders or managers. Do the stakeholders and managers gain value from these meetings — Yes, but the real value is the fact that the Team takes ownership of what they are going to deliver, they take ownership on holding each other accountable to deliver and working through problems themselves, and they take the on responsibility the responsibility of improvement.

A lot of times we (as in Managers, Scrum Masters, Team Leads, Type-A Team Members) want to install processes and templates around these meetings. This usually happens after a few weeks or several months of trying an agile framework and either not following the guidelines of the framework or the team not taking the initiative to make improvements. We’re not getting any value and the team is resisting and or blaming the whole concept — we want to fall back to more structure and being told what to do.

A great example of this is when a team’s stand ups start becoming mundane, over-run their time boxes, and team members don’t show up. So what happens is we come up with a template for the team to keep up with for daily stand ups as well as establish a set of metrics we answer to during the stand-up. And of course, this just becomes one more thing for a team member to keep track of as well as an unintentional mechanism of command-and-control.

As an ex-Director/Manager, I often wanted to step in and help — and I usually would come up with a template and or some hard-prescribed structure and tell the team to follow it. I wanted to help and that’s what managers genuinely want to do, but I was quickly put in my place when one of my team members said, “let us figure it out, it’s our problem.” I gave guidance and advice, but otherwise I got out of the way. I let the Team come up with how they were going to make their meetings more effective. And at the end of the day, they simply looked at the frameworks themselves and decided to more closely follow the existing framework guidelines — e.g. keep stand-ups at 15 minutes and stick to the script, then allow the time remaining to become open space troubleshooting time.

TeamworkAt the end of the day, remember that more process does not equal more better. Rely on the Team to solve problems, over instituting process and templates to solve problems. I think I’ve heard this before somewhere …

Agile Approach to Problems Found While Testing “In Sprint” Stories

in Agile Engineering by

Elevator shaftPicture this hotshot, you are working on a team that has recently made the transition to agile. You are a traditional tester. A developer just let you know that you can start testing the story that the two of you are working on during the sprint. You start working through your test cases, and “BAM” you found a problem …what do you do? …what do you do?

Ok, well if you stick to a traditional approach, you would create a defect in a bug tracking system, spend some time documenting the replication steps, create and attach screen shots to the bug, add test data to the bug, and then you would either notify the interested parties or you’ll just let the bug tracking system do that for you. At this time, it’s usually up to a development lead or project manager or business analyst to review the bug and determine if it is really a bug. If it is, they would assign it to a (or the) developer to fix and you (as the tester) may create a new test case to verify the bug is fixed as well as re-execute the original test scenario.

Now you’re saying, “Matt, what’s wrong with this?” And I will say, “Nothing, if you don’t care about finishing the story or delaying delivery or incurring technical debt or just putting out crappy product.” Maybe that’s going too far, but what this approach does is a number of things:

  1. The approach instantly puts up a barrier between the Developer and the Tester of a story. If not by introducing the intermediary process, but by simply calling it a “bug”.
  2. The approach promotes throwing bugs surrounding a story back into the backlog; thus, requiring us to find some way to associate the two (creating administrivia) and requiring the intermediary step for someone to evaluate the bug and decide when it needs to be fixed.
  3. The later part of #2 is the biggest problem, if we find a problem with a story being implemented and then make it a decision about fixing it then we are doing two things — letting the process possibly delay just getting it done and we are setting ourselves up for delays and debt.
  4. The approach possibly introduces waste surrounding the documentation of the issue.

The way you would handle finding an issue using an agile approach, is that when you encounter an issue while testing the story — instead of creating a bug in a tracking system, you are going to talk. Yes, that’s right — you are going to rely on “Individuals and Interactions over Process and Tools.” When you find the issue, you are going to grab the developer that you are working with on the story and review the issue. Together you can decide, is this something that is not finished, it’s a bug that has been introduced and the developer simply needs to perform a task to fix it, and, maybe – you both are going to walk over to the product owner (customer) and discover is this a bug or a simply a missed design requirement. Nonetheless, you are going to deal with the issue instead of launching it into the ether to be triaged, verified, and resolved sometime in the future. If you cannot get in touch with the developer — maybe you are divided by geography and timezone, then you may flag the story as blocked and quickly document the challenge being presented by the issue. Let the product owner know about the issue and be sure to bring it up during the next daily stand-up if it has not been resolved.

Here’s what this approach does for you:

  1. Drives a “Team” atmosphere and makes the issue both the Tester and the Developers challenge.
  2. Ensures that we don’t amass Technical Debt. Not to mention, you can avoid having issues/defects possibly slip through the cracks due to oversight or purposeful decision to let it slide out the door.
  3. Makes for a better product by having another opportunity to discuss the solution. The challenge found might be a result of the design and or requirements that may be wrong or misunderstood. It’s best to discuss these things as they happen to keep them fresh and when the story is delivered, it looks polished versus having “known issues.”
  4. Reduces costs in the long run. By not pushing issues, even for a few days, you can prevent the possibility of propagating the issue and having it impact other areas of the product. Thus, reducing rework and eliminating waste.

Now, I’m going to guess you are saying, “Matt, that sounds good — but it wouldn’t work here.” Well, I say “Why Not?” Sometimes, this doesn’t work is when you’re team’s stories are still too big to design, build, and test in an iteration. Thus, your testing is happing in the next iteration and issues found are recognized as new work. This is simply an inspect-and-adapt thing where the team needs to continuously refine the stories until they can commit to finish it 100% during the iteration. The other reason this often occurs is a command-and-control culture which may be driven by processes that are already in place or simply people that feel they must have their hands on every aspect of the development cycle. There’s not much I can suggest about adjusting the culture side besides just starting taking a more agile approach to handling challenges and let that approach prove out that it works better — trust me, it does.

Let me know about your experiences — I’m interested about your challenges, ideas, and methods you’ve used to change the culture or ways you’ve instituted an approach to issues that promotes agile principles.

How can Scrum Masters help their teams to Self-Organize?

in Agile Engineering/Teams by

Working togetherSometimes, teams need a little nudge to help to self-organize. Remember self-organize means the team takes ownership of not only how to produce the desired end results, but they are active participants in understanding the product/project and they work together to ensure they are operating as a team. It is not too uncommon for teams to sit back and wait to be told to self-organize. I usually see this with newly formed teams or teams that have historically worked under command and control environments.

A colleague of mine argues that most people operate this way — they want to be told what to do. Part of me agrees with this concept, I see this during training sessions all the time. But I don’t think this lack of self-starting self-organization stems from people not knowing how and needing to be told. Instead, I think it’s people waiting to be given permission. This behavior comes through loudly in training sessions with folks new to Agile. I’ll often use various interactive facilitative techniques during training and it usually takes at least one person to help get the interaction going. Some of the tricks and advice I’ve used and received not only works during training workshops, but I think the same things can be applied by Scrum Masters (as well as those folks in leadership positions) to help kick-start or trigger a team to self-organize. Here they are:

Practice the Pregnant Pause. The idea is that if you want to trigger conversation, create silence. Here’s how it works, state the problem or objective, or simply a broad statement that you want to trigger conversation about. Now, here’s where the fun begins – count to nine. Let the silence begin. In fact, if you have to count to 99 — I guarantee that someone will break the silence. A good friend of mine called it doing a Michael Cain, say something and throw a long pause in there and just let the team fill in. If they don’t, then maybe the meeting or discussion is over.

post it on white boardStorming. I’m not referring to Tuckman, instead I’m talking about brainstorming. There are some great techniques that you can leverage out there that will get team members involved, even those people that are normally quiet. All you need is a whiteboard, maybe some easel paper, post-it notes, and some markers. It is a amazing to see what starts happening when someone throws out a question or a problem statement, and then watching a team start brainstorming ideas.

Get Out. Yes that’s right, sometimes it’s best to just throw out an idea and instruct the team to come up with the solution, and then walk out of the room. I’ve done this myself, and I’ve never been let down — even with brand new teams.

Become a Facilitator Master. Above I mentioned brainstorming, to do it well you’ll need to practice and learn some techniques. There are many good books that can help, [amazon_link id=”0596804172″ target=”_blank” ]Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers[/amazon_link] by David Grey, Sunni Brown, and James Macanufo, [amazon_link id=”1591843197″ target=”_blank” ]Unfolding the Napkin: The Hands-On Method for Solving Complex Problems with Simple Pictures[/amazon_link] by Dan Roam, and [amazon_link id=”0470601787″ target=”_blank” ]Visual Meetings: How Graphics, Sticky Notes and Idea Mapping Can Transform Group Productivity[/amazon_link] by David Sibbet. Taking a few hours to read the books and a couple hours practicing some of the facilitating techniques will carry you a long way and help the team out greatly.

Have Some Fun. It sounds easy, but it’s been shown time and time again that the team’s productivity is often related to their attitude and the general feeling around the project. When the team starts getting too busy or too tense — this is the time when the Scrum Master should step in, assist, slow-down, or just feed the team with encouragement and substance.

How do we change from individuals in workgroups to effective, self-organizing teams?

in Agile Engineering/Teams by

A colleague of mine at VersionOne, Dan Naden who works to support the Agile community, delivered several open questions from a recent Agilepalooza and asked for help answering. The one that jumped out at me and my experiences was “How do we change from individuals in workgroups to effective, self-organizing teams?”

Team hugWhen I first started looking at this question, I was keying in on the word “individuals” and how individual team members impact our ability to come together and self-organize. The more ideas I got down on paper, the more I came to the conclusion that it is generally not the individual team members that prevent teams from self-organizing and becoming effective. It is usually everything but the individuals that prevent teams from self-organizing. Based on my experience where I’ve lived through an inability to self-organize to efficient self-organization — the individuals are usually never the primary blocker. The things that I’ve seen prevent teams from becoming effective and self-organized are:

  • Teams Are Too Large. Teams that are too big will not self-organize because the team members are made insignificant because their contributions may or may not impact the overall product delivery. Not too mention that when teams are too large you will usually see the Alpha team members overpower and control the non-Alpha team members. This is why the recommended team size is in the single digits (I’ve seen the range of 5-8) thrown out there. Not only does right-sizing the team make planning more efficient, but it also reduces the discussion circle; thus, making it easier to share information and shorten the time to make and react to decisions that impact the team and the projects.
  • Workspace Challenges. Studies have shown that the right workspace leads to highly productive teams and in talking with many teams, it’s obvious that the wrong workspace fosters silos as well as the perception of meetings purgatory. Ideally teams are co-located and share a workspace that is conducive to easy chair-spinning conversation. A workspace with plenty of whiteboards, private zones, and an information radiator will ensure a well informed, collaborative team. When this cannot be achieved, the use of rapid and personal communication tools can help teams. IRC chat, video chat, and online collaboration tools are good ways for team members to collaborate.
  • No Vision. There are multiple layers of vision – company, product, project, and team. Obviously a team can control their vision; however, it’s usually a product of the upstream visions. So if the leadership and stakeholders are not sharing the vision. And more specifically, if the team does not have a shared vision of what they are working towards, then there is nothing to bring the team together to achieve. A clearly communicated and shared provision provides a group of individuals a common goal to achieve — this improves focus on decision making and clear definition on what it means to done.
  • The 3 C’s. And I’m not talking about Ron Jeffries’ Card, Conversation and Confirmation — I’m referring to a Command-and-Control Culture. It seems that even once a leadership team decides to adopt agile and they genuinely buy into agile values and principles, the individuals on the teams are still reluctant to take ownership of how to win (a.k.a. achieve). Not until the the team is forced to make decisions, do they actually make decisions. Team members that have worked in a culture that is historically command-and-control tend to have either a victim mentality in that they simply don’t believe change is happening, or they simply are scared to put their neck out there in fear of reprisal even when there’s never been a history of this kind of action. The only way that I’ve experienced changing this culture is to have the leadership share the vision and then leave the room (a.k.a. get out of the way). When the team has success, the leadership shouts it from the rooftops and when failure occurs the leadership should ensure learning and accountability ensues — however, doing so from a distance.
  • Lack of Shared Trust. A core challenge that organizations (the whole organization) have is the inability to trust others to make decisions. This usually stems from two factors: (1) a command-and-control culture that is a result of traditional project/product failures, and or (2) management team members that have been key to the organization over a period of years and have lived the battles — thus, they feel that because of their experiences — they must be a part of the decision. Remember that trust can go both ways, if the teams don’t have that shared vision — then trust of those making decisions is surely lacking.

So, how do we change from individuals in workgroups to effective, self-organizing teams? We give our teams the environment they need to be productive, provide a clear and shared vision, have leadership get out of the way yet be there when needed, and finally we celebrate our small wins and ensure that we learn from our failures (I’ll assume that this stuff sounds familiar; however, if it doesn’t give this a read www.agilemanifesto.org). I’m sure there are more organizational behaviors and I’m certain that individuals impact our ability to self-organize, but I firmly believe that everyone has the ability to work as a self-organized team and if they are empowered to do so — they will do it effectively.

Please let me know what you think. What are some organizational challenges that you’ve experienced that prevented teams of individuals from becoming effective, self-organizing teams? Or, do you think the organization has nothing to do with it and it’s the individual team members?

Loving Me Some RSA Animate – Motivation

in Agile Engineering by

A large part of agile and making it really work is the people.  In fact, the organization can only support and foster the right mind-set through the behaviors of the leaders and the “walk-the-talk” mantra.  Ultimately the success of agile and the organization are the people associated with it. Thus, bringing me to the viral videos from RSA Animate.  RSA is an organisation that aims to trigger thoughts and share ideas — some are very clear and common sensical, while others concepts they discuss can be controversial and much deeper.  In all, they’ve published docs, videos, and held conferences that bring ideas and enlightenment forward.

Which brings me to a one of my favorites that I share constantly during agile training sessions – Dan Pink’s discussion on motivation. This discussion is based on Dan Pink’s book Drive, it is a fairly quick read and reasonably priced on Kindle.

[amazon_enhanced asin=”B004P1JDJO” container=”” container_class=”” price=”All” background_color=”FFFFFF” link_color=”000000″ text_color=”AC0020″ /]
Go to Top