Tag archive

agile project management

What Does Every Agile Development Team Want?

in Agile/Agile Engineering by

Win! Duh, Winning!

Okay, I know that is so 2011. But it is only human nature to want to not be put in a losing position, in fact we talk a lot about winning. We are naturally competitive, some folks more so than others — you know who you are. This may be an evolutionary thing because of our need to be adaptive. I’m not saying we are totally dog-eat-dog. We like to be able to look back and see that we did our best or that we delivered the best as a team. In my opinion, we win when we meet or deliver beyond our own expectations as well as the expectations that we helped others to set.

As an agile development team, when we set commitments at the beginning of the iteration, we are setting expectations to win. If we miss our commitments — clearly we are not winning. This sometimes can be compounded when teams don’t even try to innovate and adapt in an effort to overcome our missed commitments. In these cases they are complacent, and they quit trying to get better, which means they clearly are not going to win. My guess is that most people on these teams are not very happy, and especially not happy to be on a losing team.

Let’s face it, winning is hard. Outsiders (a.k.a. stakeholders including customers, executives, management, and other teams) will levy expectations upon us and the team, many times these expectations seem unrealistic and, at times, seem maliciously imposed. Also, in order to win, you sometimes have to lose — winning takes practice, which means you and your team will likely fail before you win. Often winning is hard because we are trying to do so as a team. Becoming a team is a whole blog on it’s own; however, remember that in Agile we measure outcomes based on the team. So we win and lose together.

I am not really the one to ask about winning and I know there is not one single formula to winning. That being said, I have made some observations of winning teams, they are:

Set Proper Expectations. I think this goes without saying, we’ve talked about it before — part of being successful means setting the right expectations and having all the right parties in the room to agree together on expectations. This doesn’t mean that at times we shouldn’t stretch ourselves to be better, but the rules of winning should be agreed upon before we try to win.

Be Consistent. Now, you can consistently lose, but we are not primarily talking about losing here. When I say “be consistent,” maybe I should say “establish consistency.” In that we should establish consistency in both the Demand side and Supply side of the delivery equation. Smoothing out peaks and valleys improves the likelihood of meeting shared expectations and making the act of setting shared expectations easier.

Try. If you don’t try, you can’t win — ’nuff said. Well, let’s be a little more specific. Teams that don’t try to set the right expectations, or teams that waiver from their end goal because they are not on board simply will not win. These are the teams that are often the superheroes and they’ll end up within Sprint Burndowns that never reach zero.

Rely on Strengths of Team Members. Everyone on a team has different skills and strengths — both tangible and intangible. Although it is sometimes good to work outside your comfort zone so that you can develop, when teams constantly do this or team members take on activities that reside more in their weakness zone, it’s really hard to get things done and meet expectations. Try creating a skills catalog for your team and try out Strengths Finder. Doing this together and making it visible helps team members to put themselves and others in positions to win.

Embrace Adversity and Diversity. We should not only embrace adversity (a.k.a. challenges and failures), we should also embrace diversity (a.k.a. team member differences). When something goes wrong, it should always be a learning experience, even if that learning is, “we shouldn’t do that again.” A team that picks themselves up after failure and moves on is generally a stronger team in the end. From a diversity perspective, with Agile teams we look to build cross-functional expertise. Well, it’s also good to build cross-cultural teams. I’m not talking about putting someone on a team who is totally a bad fit, but instead — introduce a team member that will bring new ideas and approaches to solve a problem. Plus, with diversity generally comes new experiences — which is usually a good thing.

Tennis PracticePractice. It goes without saying, you don’t get good at something without some practice — look at professional sports teams. Yes, there are those of us who are naturals at certain things — but even the naturals need to practice. When we practice, we learn – we learn new ways, better ways, and ways not to do something. Yes, we might experience beginners luck every-now-and-then; however, by practicing what is often unnatural to us becomes natural — then we can focus on the next level of challenges.

Apply New Techniques and Tools. As we practice, we should always be looking to find a new way to do something or seek out opportunities to improve some aspect of what we do with tools. Although I work for a tool vendor, I’ll be the first to say that tools don’t always solve a teams problems — people have to solve the problem. But tools and new techniques can improve the way we do something or make a solution more reachable. Not to mention, new techniques and tools can make solutions more effective and efficient.

Put Our Best Foot Forward. Simply put, don’t put anything out there unless it is something you would put your name on and parade it in front of the world. A team I once worked with used to have “Good Code, Bad Code” sessions. This was a community of practice meeting where the developers would present examples of either good code or bad code. The author of the code generally remained anonymous; however, you were really nervous that it might be your code about to flash up on the screen as an example of bad code.  This type of discussion really forced everyone to raise their game, but at the same time if your code was brought up — you had the opportunity to discuss the circumstances and understand a different way.  Nonetheless, you always tried to put your best foot forward.

So those are the observations and experiences I’ve had around winning teams. In your experience, what makes up winning teams? Or, is something I said something you agree or disagree with? I really think teams want to be successful, it’s human nature. It doesn’t mean we always have to win, but it sure is fun and everything is easier.

Twelve Awesome Interactive Facilitation Techniques for Agile Teams

in Agile/Agile Engineering/Product Management/Project Management by

If you work with a team, and possibly, you are the Scrum Master or Lead or Product Owner, or just a Team Member trying to guide a conversation — then these interactive facilitation techniques are for you. But before we move on, let’s first get it out there that we may call these “Interactive Facilitation Techniques”, but they are really games. More specifically, games that help us at work. Using games — I mean interactive facilitation techniques — help us to effectively and easily facilitate discussions. Using these games to helps to drive good team behaviors (Blunt 1993) including cooperation, clarifying, inspiring, risk taking, harmonizing, and process checking. All the while, helping to overcome the destructive team behaviors of dominating, rushing, withdrawing, digressing, discounting, and blocking. That all being said, let’s get to it. The following list of games are those that I’ve personally used with teams that I see work really well and are easy to adapt. I’ve taken the liberty to group them by the team meetings where they make the most sense; however, as I previously said — they are easy to adapt and can be used for almost any activity.

General Brainstorming

Affinity Mapping – An oldie, but a goodie — this great way to collect, organize, and rationalize ideas — even large amounts of ideas. I’ve used this to help understand the objectives of meeting attendees and get everyone on the some page. Here’s a great a time-lapse video of a team using Affinity mapping to sort 500 pieces of customer feedback…

Dot Voting – Dot voting is a simple way to get a group of people to form consensus. This technique let’s everyone have a voice and it’s a quick and easy way to rank things. By the way, here’s a cool and FREE tool to do this with distributed teams … http://www.dotvoting.org

Pre-mortem – First off, let’s remember that words mean things and mortem is related to death. So I equate doing a pre-mortem to death planning including making your bucket list, understanding what things you should do to be health, and things to do to stay safe. The pre-mortem is a great risk management technique.

Discovery

Product BoxProduct Box – Also known as Vision Box, this is a great way to discover what customers think, a way to uncover expectations, and ultimately share – or gain a shared understanding of the product or project or release. I find the product box to be a great exercise for Release Planning and project chartering.

My Worst Nightmare – This is a great way to get into heads of the team and learn from their experiences, anxieties, and expectations. An easy way to express yourself, you use pictures. They say a picture is worth a thousand words and it’s true. I use this exercise to prime the pump on understanding objectives.

Spider Web – Another game from Innovation Games, Spider Web is a form of context diagramming, but it’s no the run-of-the-mill context diagramming. First, everyone get’s to draw, second — use pictures, and finally, no rules — lines can go from one item to another. You’ll find this a great game to understand information flows between people, systems, and organizations.

Requirements

Staple Yourself to Something – Have you ever found that getting started is the hardest thing to do? Well, this is the perfect game for you. This game involves mapping out processes, it helps to quickly get everyone on the same page as to how something should work. It helps with knowledge exchange, establishing process flow, and establishing a shared understanding.

Empathy Mapping – Establishing personas is a key activity at helping to understand our customers or the users of the systems we are building. This technique is a fast-and-easy way to do understand our users as a team. Even if you already understand your personas, let the team do this exercise and see what they discover.

Buy a Feature – Have you’ve ever been frustrated with stakeholders not being able to make prioritization decisions? Buy a Feature is an awesome way to help drive the discussions around prioritization. You may not land on the final ranking, but you will gain some awesome insight into what is important and where people are willing to negotiate.

White Elephant Sizing – This is the only way to estimate stories. Okay, not the only way, but it’s a good way. This game is a spin on the White Elephant gift exchange we do after the holidays. The values of this game are conversations and shared experiences of all the players. If you want to find a fast way to estimate, try this.

Retrospectives

SailboatSailboat and 4Ls – I’ve talked about both of these games before, and I play them regularly to help evaluate coaching sessions. I encourage folks to mix it up all the time with regards to retrospectives, and these two games are great ways to do it.

Learning Matrix – This one is from Diana Larson and Esther Derby’s Agile Retrospectives book. What I really like about it is that you find things to improve upon based on looking at what you are doing right. You review where things are going well and look at how applying what you are doing well to this things that are going wrong.

Check out the AgileBacon links page for sites that are all about Games that Work.

If Your Title Rhymes with “leaf”, “erector”, or “resident” – You Should Learn About Agile and Lean

in Agile/Project Management/Teams by

If you are reading this blog, then you are either part of an Agile transformation or you are someone considering an agile transformation. If you are someone that works in a management or simply a position of authority at your organization, if you don’t know much about Agile or Lean except that they are the latest buzzwords that don’t seem to go away — well, you should learn more about them. Because, the words might change a little, but the practices and principles have been around for a while and they are not going to go away anytime soon.

Agile and Lean are a set of ideas and principles that shape principles which guide our behaviors and foster the frameworks by which teams use to get things done. These have come about because there’s a recognition that trying to build things that are a result of complex cognitive thinking cannot be done well and in a timely manner to keep up with the demands of consumers. Couple these demands with an exponentially growing and aggressive competitive marketplace — the concepts of focusing on building the right thing and eliminating the waste that keeps us from delivering things right have naturally emerged. Agile and Lean are not old ideas, there’s been a ton of learning and shaping of these ideas and principles. New frameworks and or practices emerge daily as our products evolve and the people creating them do the same.

Why Should You Learn Agile and Lean?

clone_dollyHave you ever said, “Dolly is a great leader and worker, I wish we could just clone her and have ten Dolly’s.”

Or, how about, “I wish our team would just make a decision and get it done.”

Well, Agile and Lean values promote:
[list][list_item icon=”fa-star”]Empowerment[/list_item][list_item icon=”fa-star”]Trust[/list_item][list_item icon=”fa-star”]Commitment[/list_item][list_item icon=”fa-star”]Quality[/list_item][list_item icon=”fa-star”]Value[/list_item][list_item icon=”fa-star”]Team Work[/list_item][list_item icon=”fa-star”]Transparency[/list_item][/list] All of these things involve, giving teams information and the vision, and then getting out of the way to let them deliver.

Another thing to note about the values above are that they are generally practiced by all organizations and you’ll find aspects of each word above within the corporate mission statements. By learning more about Agile and Lean, you can learn how to help your teams or leadership leverage the organizations’ values and adapt those advocated throughout Agile and Lean adoptions.

The predominant reason organizations and teams adopt agile is to respond better to change — that is market changes. The other reasons are productivity and quality, all things that help us make products people want to buy, at the price they are willing to pay, and ultimately with the right level of quality that help mitigate long-term cost of supporting. A byproduct of agile adoptions is improved morale.

How You Learning Agile and Lean Can Help

cycle, loop or feedback conceptAgile and Lean advocates shrinking the feedback loops which improve communications amongst departments and ultimately help your employees make better decisions. Well, you understanding when the feedback loops happen, your role in the feedback loops, and the types of information shared at the different levels of the organization can help you keep yourself out of the way from the team. What I mean by this is that when sometimes things are going right, we’ll go back to what we are comfortable with and understand — and generally this means metrics and reports that may be costly to gather and result in anti-patterns for good team work.

The other value of you learning about Agile and Lean is that you can help facilitate the adoption by being a good leader and facilitating change practices. Keeping a level head when things aren’t going right, and providing guidance as to how best support the teams.

What Should You Do to Learn?

There’s a ton of reading materials out there. Just keep in mind that there’s a lot of books, articles, and blogs that focus on the practices and not as much on the strategic and scaling aspects around agile. This spaces is growing as organizations have realized that not only is there the “build better software” value, but the planning and practices around Enterprise Agile give organizations a framework to make better investments and harness the short feedback loops to improve ROI.

To help get you started, here are a few resources that have been recommended to me and I can vouch for their value of learning:

The Agile Executive Whitepaper, Jim Magers, VersionOne. Nice quick read and primer / introduction to agile.

The Concise Executive Guide to Agile, Israel Gat. Nice quick read that provides a deeper dive than the Agile Executive whitepaper.

Scaling Software Agility: Best Practices for Large Enterprises, Dean Leffingwell. Foundations for the Scaled Agile Framework (SAFe) which is being advocated as a framework for leveraging Agile and Lean in the enterprise.

Principles of Product Development Flow, Donald Reinerstsen. Helps explain the way Agile and Lean works in Product Development.

Training – Agile for Executives Workshop, VersionOne. This is a workshop that I’ve performed as well as my colleagues and it’s aimed at being a concise four hour session aimed at ensuring Executives understand the history, underpinnings, and execution models surrounding of Agile and Lean.

Words Mean Things – Maniac or Bacon

in Bacon/Randomness by

Well, it has been almost three years with the maniac and now it’s time for a change.  Actually, what has occurred is that some nice person told me, Matt, to Google the definition of maniac.  So I did, and here’s what I found:

maniac (plural maniacs)

  1. An insane person, especially one who suffers from a mania.
  2. A fanatic, a person with an obsession.

At first glance, I thought — well, that works. But I quickly realized, maybe I am crazy, maybe I am a fanatic. Ok, I’m really not — at least I don’t have that perception of myself. In any case, I realized that maybe I should change this because, really I don’t prescribe to the heavily prescriptive approach to anything. I believe in visioning, informing, building, and realizing — I don’t care how I get there, I just happen to feel that Agile Development Methodologies or Agile Project Management is a great way to get there.

That brings us to bacon. Why bacon? Why not? I for one am a big fan of bacon, you can add it to anything and have it enhance the experience. Not to mention, I like to keep things simple and there’s not anything more simple than bacon. Not to mention, to steal from the Chicken & Pig metaphor — I think we are all pigs and we are all committed.

So without further ado, I introduce agilebacon.com. This blog is roughly the same as the old agilemaniac.com, except it is new and improved! I’ve already added some cool features including a Link Library, an embedded Glossary that will provide definitions in-line, and, of course, we have a new look and feel that provides much better readability than ever before.

Please let me know what you think! Comments are open below, my new Twitter handle is online – @agilebaconbeer, and I even broke down by creating a Facebook Agile Bacon page. Thanks again for coming by and giving me a read, and please visit often.

Five Ways to Establish Trust

in Agile Engineering/Product Management/Teams by

As everyone knows, a key success factor of an agile process implementation, specifically Scrum, is establishing trust between the team delivering and those waiting on the delivery (basically between the product development team and the business).  In order to establish trust, a development team should be meeting their commitments made during the planning meetings; thus, delivering what they said they would.  Sounds like a pretty simple formula and for the most part — it is.

Never trust the teller. Trust the tale.
– DH Lawrence

Outside of simply delivering what you said you would in a sprint, here are five ideas to establish trust:

  1. Always act with integrity. It goes without saying, truth sets you free.  But what is more than simply being honest while communicating with someone, but it is more important to perform your job duties with integrity.  This means, no cutting corners, maintain the utmost quality, and always keeping the team informed when it comes to matters that may impact the core deliveries.
  2. Ask questions and share information. Make sure that if an idea is not understood, be sure to not be afraid to ask a question (sometimes, the first thing that comes out the mouth is “I don’t know”). Be sure not to assume you are all-knowing about an issue, so share what you know — this is an excellent way to facilitate conversation and potentially discover what you don’t know.
  3. Reasonably accurate expectations (estimates to complete). In the agile world, estimation can be challenging.  This is primarily due to the lack of data present at the beginning of tasks.  The easy way to overcome this and become more accurate with your estimation is to be sure to break down stories into common development tasks.  This may include an analysis, design, build out, unit test, etc type task.  I also like the proto-type, stub, or even the sub-functional task where a small piece of functionality is implemented.  Estimates generally get better the smaller the task and they are of course better when more than one person sets the estimate (leveraging the experiences of others will help).  Finally, always accurately update estimates to complete daily.
  4. Deliver within the boundries of the commitment. Simply stated, don’t always try to be a hero and deliver beyond the expectations of the original commitment. This can be viewed by management (be it product or development) as sand bagging estimates, or simply going rogue and “doing as you want to”. Not to say that finding a great way to do something that was much more productive is not a good thing or seeing that you can do a lot more within the context of the product functional area is not appreciated. But the right way to handle this is to disclose that you found a faster way to do something and your estimate-to-complete is much less than orginally anticipated, so you would like to work on another key capability that is similar to the functionality being implemented. Negotiating this within the context of the daily standup (and possibly within a follow up meeting) would be the correct course of action.
  5. Consistency is key.  Having one good sprint is not enough, a team needs to establish a trend of delivering on sprint tasks on a consistent basis.  This applies to the team as well as the individual.  Once a team is able to demonstrate a consistent trend surrounding capacity, story points delivered, hours worked, etc — the product stakeholders can start to reasonably expect that what the team says they will finish will in fact be delivered.

Remember the idea of trust should also exist within the scrum team and between scrum teams where there is a need to share deliverables or even if you all work within the same development organization. The five ideas above should be applicable to ensuring that all scrum teams work well together and within the overall scope of an organization.

What techniques or ideas do you have about how to build trust with the product management or project stakeholders?  What have you’ve done that works?

Go to Top