Category archive

Agile - page 2

Best Day Ever

in Agile/Humor/Product Management/Project Management by

My dog Mocha has a great tail — her fur is fawn colored and her tail has a white tip. My wife and I call Mocha’s tail the Happiness Meter. You see, you can tell how Mocha feels based on what her tail is doing. She has multiple wagging patterns:

TailPatterns

Every morning, when I wake up — Mocha is there with her tail going in the helicopter pattern. Yes, this means that she is extremely happy to simply be waking up to another day. She does this every day — to her every day is the BEST DAY EVER. The one thing to know about Mocha is that she’s getting older, she definitely has stiffness in her joints, she has a bum knee, and she suffers from bouts of mild pancreatitis. Even if Mocha went to bed not feeling well or wakes up stiff — her outlook is always, this is going to be the BEST DAY EVER.

We’ve all heard of the power of positive thinking — heck, there’s probably a couple hundred books on Amazon written about or referring to the power of positivity. But since we are humans, it’s difficult to squelch down the trials and tribulations of day. In the software development world, we talk about “the death march.” This is that project that drags on, is considered a failure before the first user even sees it, the one where the management tells folks to work on the weekend, the one where for every bug fixed someone finds two more. If you work in information technology, then you’ve been on one of these projects.

Now since you are reading an Agile blog, you are probably waiting for the Agile Punchline or to hear about the Agile Secret Sauce to help over come the challenges of these projects. Well, the reality is that Agile generally will expose problems earlier and maybe make you realize that this project is going to be painful and heading for certain doom. We hope that we course correct or try something different, but sometimes we are simply just in a bad place and cannot get out of the rut.

So while working on these projects, people come dragging in for another day of drudgery. Another day of running on the hamster wheel and not getting anywhere. Another day that the project is dragging us down — in fact, today just may end up as the worst day ever.

Remember, today didn’t start out as the worst day ever, it started as the BEST DAY EVER.

  • Today is the day that no matter what happens we will find something positive and see how today is better than yesterday.
  • Today we will find that our small failure is just that, a small failure — and we learn from it, and have a piece of knowledge that we didn’t have yesterday.
  • Today is the day that we celebrate finding defects, because those are defects our customers did not find.
  • Today is the day that we find joy in having to refactor some old crappy code, because we know that when the next developer visits that code — they’ll get to enjoy changing it, not dreading the fact that they are likely to break something.
  • Today is the day that we move one day closer to getting the project out the door.
  • Today is a great day to laugh with a coworker.
  • Today we admire what has been accomplished versus what is remains.
  • Today is going to be the BEST DAY EVER.

And if you don’t believe me, just ask Mocha.

Getting Blood From a Turnip – Agile DC Slides

in Agile/Resources by
Facilitation Games

So this past Tuesday, I had the privilege and opportunity to talk to the AgileDC crowd about some fun facilitation techniques. It was a great session, primarily because everyone played along — so thanks for making it fun. Please let me know if you would like the original slides.

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.

Why I Love the Boards We Use In Agile Software Development

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

I know this is going to sound weird, but I have an affinity for the boards we use in Agile Software Development (or Agile Project Management). I’m using the generic term board, but you may refer to them as Storyboards, Taskboards, Testing boards, kanban boards, or simply job boards.

If I get into the way-back machine; back to when I first started my career. I was in Valdosta, Georgia working my first job out of college, Trus Joist MacMillan, and I was being walked around the manufacturing facility. I was in awe and deep appreciation for what I was learning. As I went through the customer service area, I noticed a large magnetic board and on it were these color coded cards with lines that represented stages and dates running across the top. I inquisitively asked, “what is that?” They quickly and proudly gave me the run down that these things all represented our customer’s requests for goods (a.k.a. orders). The columns represented stages of the manufacturing cycle and the lanes represented weeks. This board was the central information hub for the plant — the board described everything going on from department-to-department. It gave the all plant team members indicators as to how well are we satisfying our customers, what’s coming up for the next week, and which customer orders were being held up. The other thing I noticed is that as you went throughout the facility, other departments had similar boards that were a reflection of the main board but for the specific customer requests they were working and the boards reflected each departments workflow.

Does this sound familiar?

If it doesn’t, then you are probably not working in an agile world, or living under a rock, or you are using agile by you are missing out on something great. Me and my colleagues talk about metrics a lot – with our customers and internally. Well, in case you didn’t notice, the boards themselves are living breathing metrics. The boards are the team’s communications central as well as a key way to see collectively “how are we doing?”

In fact, the boards often ask just as many questions that they answer. These questions can vary based on your role and whether or not you are an embedded team member using the board or a bystander looking to gain insights from the board. I took on the the challenge of looking at questions asked and answered by the boards and found 40, yes 40 — check them out on this mind map. I’m sure there are more; however, I figured 40 was a good start and stop.

Mindmap of Questions with Boards

Besides all the questions boards ask and answer, I also love boards for their ability to simplify the portrayal of real-time information while being able to have complex information tucked away in the details. Teams can easily innovate and adapt their boards with the use of colors, pictures, lines, layouts, materials, etc.

Finally, I love boards because they actually build the teams. They provide a place to recognize accomplishments, share challenges, and they are the place to stand around and talk about what is happening on the project. If you are using an electronic board, you can still gain these valuable intangibles by keeping the board up-to-date and driving all collaborations on what is happening on the boards. Boards give teams focus, while also given them information that empowers them to make decisions to get things done and meet commitments.

Please share your thoughts on why you like, love, or hate the boards your teams use. Share some examples. If you are not using a board today, why not? Trust me — you will be glad you did.

Checkout this gallery of board examples that I found:

v1storyboard
v1epickanbanboard
Neon Board
Quadrant Board
magnetboard
kanban-full1
IMAG0033_thumb[2]
dsc_0281
bigboard
Agile Task Board

Presentation – Attempting to Jump the Largest Agile Hurdle

in Agile/Project Management/Resources by
Agile Culture

Had a great time recently talking to the PMI Atlanta – Agile Interest group. Great participation and lots of fun, nice people. Please check out the presentation and let me know if you want to have this discussion at your organization.

1 2 3 4 6
Go to Top