Tag archive

teamwork

10 Causes of Chaos in Agile Software Development

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

“Everything is so chaotic”
“Seems like we are constantly in a state of chaos.”
“Is agile always crazy and chaotic?”

Chaos is a word I hear a lot lately while working with software development teams that are either initially adopting agile software development or possibly undergoing a Lean/Agile reshaping to improve their existing agile approaches. I am often asked if the chaos will subside, and — the good news, it will — to a certain extent. But to best understand when things will slow down (or even if they’ll slow down), it’s good to explore some of the causes that make things chaotic with software development.

And in my world, there’s no better way to assess than to make a top 10 list:

1. New Teams Forming.

New Team

This one is obvious — as people come together to work with one another there’s a feeling out period. Usually during this period, teams are learning how to collaborate and work through conflicts. In addition to the people learning to work with one another, there are plenty of established organizational structure and culture barriers that slow the progress of a team forming.

2. Process Learning.

Complex Process

Another obvious one. Although most agile process frameworks (e.g. Scrum or Extreme Programming) are fairly easy and well documented, it takes time and practice to learn the mechanics. Couple this with #1, and well — there can be some real challenges to getting things done.

3. HEAVY Learning Mode.

Tired Student

This may seem redundant, but it really cannot go under emphacized. In addition to learning about each other and learning the process frameworks, as engineers — we are constantly learning about technologies, learning about our products, learning about our customers, well — just getting smarter. Needless to say, this all adds up.

4. Greenhorns.

Crab Fishing Greenhorn

If you ever have watched the Deadliest Catch on Discovery Channel, you get to see the struggles and pains of the first time deckhands – called Greenhorns. They are often way over their heads, running into challenges around every corner, and are just flat out exhausted. In addition to physically and mentally killing themselves, they are trying to prove themselves. Well, this is true with just about every new team member. Not only are they dealing with items 1-3 above, the intensity of the learning is magnified and until they have some wins and time under their belt, chaos exists.

5. When Quality is NOT Built-In.

Rolex Quality Built In

It is my opinion that in software development, over the years we’ve invented this approach to quality that is “risky and invites failure.” [1] Yes, I stole that — in most software development shops, quality is something that is done by different people to ensure “separation of duties” and because of the mentality that developers make bad testers. Couple that with the attitude that QA Engineers can’t or don’t necessarily need to know how to code, we have what we do today — a ton of end-of-stream testing, out-of-band automation efforts, and honestly, even the staunches of agile shops struggling with testing and ensuring quality. Without quality weaved into the Design>Build>Test cycle, we tend to see a lot more of these noisy things called Defects. Defects take a ton more time and energy than building it right in the first place.

6. Quality Automation Doesn’t Exist.

Sonar Dashboard

Without automation your going to find it almost impossible or at least extremely constraining to effectively and efficiently deliver with quality in a predictable manner. Similar to the “build quality in” challenges, teams often struggle because of their estimation processes calls quality out separately (which makes it a target for evil doers) and often it doesn’t account for the work around automation. Many organizations adopting agile software development don’t have an automation strategy for their legacy code. Therefore, they tend to have bouts of analysis paralysis around the problem space or they simply say, “our product or software is too hard to automate the testing” — so they won’t try. The other challenge around automation is some see it solely as an end-of-line UI automation thing where a couple engineers work on it — test automation is a holistic challenge and needs to be treated as such.

7. Lack of Cadence.

Perpetual Motion - Agile CadenceWhen teams are starting out, they don’t realize that the first thing to establish is their cadence — get their schedule in place and time box everything. The cadence surrounds the process touch points that require formal communication which help us to build habits; thus, making the process aspects of agile software development more muscle memory. If you feel like you are always in meetings or your iteration meetings are not occurring at the same Bat-Time and same Bat-Place, it might be time to reset — your cadence is lost.

8. Unpredictable Release Cycles.

Roll Dice

This one is an enigma, because there are teams I run into that say, “our product is to large and complex to release in short cycles” and then there are those that say, “we just release when we have to, it could be twice today or two weeks from now.” Looking at these two statements, they appear to be opposite in cause — however, it all comes down to #7 above and understanding what is the ideal batch size that reduces thrashing, allows for tighter alignment amongst teams, reduces “Integration Hell”, and prevents the amoeba style releases that never seem to end.

9. Deadline Rich Environment.

Deadline

Projects are the problem — or at least the traditional sense and meaning of a project drives the idea of fixed scope and fixed schedule. Let’s look at the PMI definition of what is a project?

It’s a temporary group activity designed to produce a unique product, service or result.

A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources.

At the end of the day, we drive our business off the idea of push for a date — we get emails from colleagues asking “when?”, we get emails from tools telling us “now!”, and we have other teams telling us “yesterday!” Ultimately, projects drive expectations which are generally dates, we can’t seem to get away from them until everyone realizes, we should design and define scope to fit the schedule, not the schedule to fix the scope — because the schedule usually flexes in these situations not the scope.

10. Estimation (and for that matter, Capacity) is Not Understood.

Voodoo-doll

We often see teams measuring productivity units of time versus being measured as units of value. This is the case even in mature agile shops. Everyone is so focused on trying to come up with a voodoo formula to determine capacity of a team or organization and another voodoo formula to normalize story points across teams in order to build a long-term plan based on the cooked up numbers. The funny thing is that in many cases the approach used for estimation doesn’t really changed once an organization starts using agile — everyone continues to predictively plan what we really don’t know. Agile Software Development is an adaptive approach to estimation and capacity. We work with what we know, we measure value, we assess complexity, and we often simply size efforts based on relative uncertainty. If people would just keep it simple, try to get all stories to the same level or near the same level of certainty, and do the same with the to-do’s (a.k.a. tasks and tests) — then in a couple iterations, teams should be able to just count the stories and count the to-dos accomplished within a time box and use that for planning. Oh, if only it could be that simple … it is.

Okay, this was just my brainstorming or brain dump (literally) of ten things that cause chaos in software development, in particular in the situations where an agile adoption or reshaping is underway. Just keep in mind, change is constant in business — now, more so than ever. Software development is complex, so are people. The great thing about tomorrow is, we don’t know what is going to happen. So, just practice and keep in mind, if today is bad — then there’s tomorrow.

Steve Jobs on Innovation

in Agile/Agile Engineering by

gty_steve_jobs2__dm_111006_wg

Sometimes when you innovate, you make mistakes. It is best to admit them quick, and get on with improving your other innovations.Steve Jobs

Put It On The Team

in Agile/Agile Engineering/Project Management 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 …

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

in Agile Engineering 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