Category archive

Project Management

10 Causes of Chaos in Agile Software Development

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

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.

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.

Words Mean Things – Efficient and Effective

in Agile/Product Management/Project Management/Teams by
[mks_pullquote align=”left” width=”300″ size=”24″ bg_color=”#117788″ txt_color=”#ffffff”]Efficiency is doing things right.
Effectiveness is doing the right things.
– Peter Drucker[/mks_pullquote]As we continue to explore words and their impact on conversations and behaviors, I would be remiss if I didn’t bring up a common set of words that generally makes me twitchy if one is emphasized more than the other — the words are Efficient and Effective. Let’s first look at the definitions of both:

effective. a. Successful in producing a desired or intended result.

efficient. a. (esp. of a system or machine) Achieving maximum productivity with minimum wasted effort or expense. (of a person) Working in a well-organized and competent way.

A lot of people talk about and use both these words — in fact, with some folks, these words are their Drinking Game words (every time they say it, you drink). If your role focuses more around management then you probably guilty of using the word “efficient” quite a bit. If your role is focused more around product quality or release management, then you probably say “effective” throughout the day. If what you do or build is largely commoditized or well established, you may tend to focus on how efficiently things get done. If what you produce is suffering in the market (either a lot of support or lack of sales), the word you probably talk about a lot more is effectiveness.

In all these cases, the context of the person or the product dictates our focus on either efficiency or effectiveness. This seems fairly harmless, but problems creep in when we might focus on one thing more than the other. If we focus to much on achieving maximum productivity, we may tend to miss key details and or skirt over a key step that insured quality. If we focus solely on effectiveness, we may see over engineering, gold plating, and an opportunity pass us by.

I’ve read several blogs lately about having efficient daily stand ups or retrospectives or planning meetings, with just a few words mentioning ensuring effectiveness. Since these meetings are about creating a team and continuously improving, effectiveness should be a key part if not the primary part of the discussion. In these situations, you could argue that efficiency would help drive effectiveness. For example, sticking to the 15 minute rule around stand-ups is meant to be a time boundary to help team members to ensure their effectiveness of their message.

EffectiveEfficientAgile and Lean principles have elements of both effective (focus on delivering value) and efficiency (while minimizing waste). If you are an efficiency junky, don’t forget effectiveness. And if you tend to be an effectiveness aficionado, don’t forget that in today’s market landscape — things have to be done efficiently. Both of these words should be used together and when we have a discussion about doing something better, we should understand how the improvement impacts effectiveness and efficiency. I quoted Peter Drucker at the beginning of this post, and it’s appropriate since his writings, specifically his book The Effective Executive has long shaped this Effective vs. Efficient model and thinking. The model shows that without effectiveness, efficiency doesn’t matter. That being said, the time window for effectiveness has gotten smaller due to competition and more demanding consumers — meaning, in his model you may not survive long.

So the next time we are innovating around our process, let’s be sure the conversation includes doing things effectively while while keeping efficiency in mind.

1 2 3
Go to Top