Tag archive

lean

Best Day Ever

in Agile/Humor/Product Management/Project Management/Teams 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.

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.

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?

Go to Top