Category archive

Agile Engineering - page 2

Behaviors and Culture Can Impair Creating Good Product

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

When we think culture, we often think about nationality and or regional cultures. Culture is often a dinner discussion with my wife and friends, it’s great to reflect upon how our upbringing, surroundings, and maybe even our genetics drive our work habits, how we work with others, and how we see and work with authority. Culture is a difficult thing to work with because it’s engrained in us.

A few weeks ago, VersionOne released the 7th Annual State of Agile Survey. Within the survey, it is obvious that culture is the leading challenge to all aspects of agile adoptions and transformations. There were two questions within the survey that really highlighted the cultural challenges (note, I plucked out the key responses that impact culture – be sure to check out the full survey):

Concerns about Adoption

  • Lack of Upfront Planning – 34%
  • Loss of Management Control – 31%
  • Management Opposition – 27%
  • Dev Team Opposed to Change – 18%

Specific Organizational Failures Behind Agile Failures

  • Failure to integrate people – 34%
  • Failure to teach team-based culture – 28%

Prior to the survey being released, I already started making a list of those human behaviors and or cultural behaviors that I’ve seen impact the ability of an organization to build good software, let alone those behaviors that negatively impact an organization’s agile initiatives. Here’s my list:

  • Controlled manFear of Losing Control. This is primarily an individual fear; however, it can also be engrained in the organization. I’ve heard, “if I don’t put these controls on how the team works and if I’m not making decisions, when they screw up — I’m the one that is going to hang.” Of course, the idea of control being lost ultimately becomes a myth, because we generally see everyone’s engagement raise up a notch or two. Thus, resulting in more people being involved in making the decisions at the proper levels — hence scaling the organization.
  • Gate Keeper Culture. Often a subset or product of Fear of Losing Control, this is the manager or director who acts the liaison between his or her direct reports and the rest of the organization. I’ve seen and even lived in environments where all communications have to go up and down the ladder. Or, where in order to talk to someone on the “protected” team, you have to walk past the Gatekeeper and they then take the message or grant permission as long as they are part of the discussion.
  • Measurement of Success is Based upon “On Budget and On Time”. Many organizations, especially IT organizations live in the world where they try only be concerned with what they can control — and that is generally, “we deliver what was signed off and will do it based on a budget and set schedule.” Well, we fail to recognize that we should be measured based on the success of the product either in the marketplace or the usage internally. The funny part is when we time box and quit focusing on the when and who, and instead focus on the what — everyone is happier including the development teams.
  • “What’s My Role” Fear. This is the protectionist behavior where managers and or team members don’t see a fit for themselves or don’t find a fit for themselves as an agile transformation takes place. These team members or managers generally start start creating barriers to deflect blame while at the same time climbing to the roof-tops to shout out about the failures of the team and process. If others are looking at the right thing (e.g. product moving out successfully
  • Victim Mentality. Have you ever heard, “it’s always been that way and it’ll never change”? Well, this is the typical response for the person who either doesn’t want to deal with change — or they’ve been told “NO” so much, they just give up. Personally I used to be one of these people, then I learned quickly — if you don’t ask, you don’t get. And, if it is something that could have really positive results — isn’t it worth the risk?
  • photodune-3820842-young-superhero-sSuper Hero Culture. Now don’t get me wrong, I appreciate hard work and stepping up your game to make sure we succeed as a team. But constantly over committing and being let to overcommit constantly is not a good thing. I’ve also seen that individual who loves to be on a pedestal, thus when we start working more as a team — they’ll often be the person making back room deals to do more work or take on the clandestine project that our Scrum Master isn’t supposed to know about. Again, hard work is great — but we have to respect the concepts of sustainable pace, transparency, and “The Team”. Remember we regularly deliver value.
  • Us/Them Culture. This one is obvious, but it takes on a few forms including department silos, role based silos, and Ivory Tower silos. Department silos exist when we have complex solutions that require the integration of products from multiple departments and a bad or no rapport between the teams. Role based silos will generally exist in early agile adoptions where the value of diversification and cross-functional teams have not been visible yet. And Ivory Tower silos are those “I’m a Director” or “I’m the Product Manager” and you just do what I say — this never results in team work, unless the team is conspiring together to take down the Tower. If people talk about the managers in the organization as “The Suits”, then you might have some Ivory Tower silos and possibly going in the opposite direction.

What challenges, either culturally or behavioral, have you’ve experienced? I’m interested to here about those that not only impacted your agile implementation, but those that impacted delivery good product.

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

Hit and Run Build Breaker

in Agile Engineering/Humor by

Funny parody on Real Men of Genius — Real Agile Genius!

[inline_media]
[/inline_media]

Common problem, someone checks in code at the end of the day and breaks the build.  Heck, at least there’s continuous integrations taking place 🙂

Thanks to my peeps at VersionOne for doing this one.  Jerry is an excellent actor, he would never leave with a broken build.

It’s Not a Bug, It’s a Feature

in Agile/Agile Engineering by

featureI know everyone who has worked in or on or amongst a development team has heard the saying, “it’s not a bug, it’s a feature.” When said, it is usually followed by some laughter, sometimes remorseful laughter. Heck, you’ll even hear the users beat you to the punch when they say, “that’s a feature, not a bug – right?”

Ding. Ding. Ding. Mr. User, you are absolutely correct!

Anything that goes out the door is a feature of our product (or anything we release to our users is a feature). Now whether the feature improves the value of our product or service, or if it detracts from the value — they are all features. We chose to release our software — we may have known about the problem or we may have known that we did not test enough or we may not have had the awareness of a unique usage scenario – no matter what we chose to release and everything in the product is a feature. Couple the concept of releasing bugs in our code with the premises around technical and design debt, well now our heads are exploding as producers of software.

Now, you are probably saying, “yes Matt, we get that … but what’s your point?”

Well a lot of organizations struggle with the concept of balancing the amount of bugs (and technical debt) in the software that we address versus the amount of new features and enhancements that we add. We often find that stakeholder who is all about the sexy or the cool — looking for that differentiator that users want.  As a delivery team, we are quick to say to the stakeholder, “you don’t get it, users aren’t going to like this and it’s going to costs us more to fix later.” This statement is 100% correct. The stakeholder, who may have a case of “rabbit ears” responding to a big prospect need and he or she may not have visibility or understanding about the extent of the technical debt within the software.

So what do we do about it and how do we find balance?  There are four things that I’ve seen work really well:

1. Make all bugs and technical debt part of the backlog. I run into folks that will manage bugs in one system and stories (requirements) in another. They need to be together — remember a bug is a feature, it’s just a negative one. You can write the bug as a story. The bugs should be ranked and treated like any other member of the backlog.

qualitychart2. Create Metrics and make them BIG AND VISIBLE. A chart that demonstrates number of bugs by severity on a specific day is not too useful to communicate this problem. But, a chart that shows a trend over the last six months the # of bugs found with a corresponding chart series that shows # of support calls for the same period and with another line that shows % of maintenance renewals — well, now you have a powerful story. How about a chart for measuring quality that is based on the number of known bugs released / number of support calls? Or, similar to this the number of new features released / number of support calls. And, how about a simple number — the percentage of our total backlog that is associated with bugs and technical debt. I guarantee a high number will get someone’s attention. Make these charts part of your team’s information radiator, post them on the wall in the break room, or start making them part of that weekly project report.

3. Conduct frequent Extermination Hack Fests. Establish one day an iteration as a bug extermination day or maybe ever three iterations, use multiple days for this activity. This is not just about having an hardening sprint, it is about allowing the engineers (architects, testers, and developers) to team up and knock out bugs with the only consideration that once you start working on a bug, it must be fixed or an approach designed to fix, by the end of the Extermination period.

4. Align resolving bugs and technical debt with strategic goals. Almost all companies have goals associated with customer satisfaction, or growing our footprint within our existing customer base, or establishing market leadership. These goals are not achieved by putting out crappy product. By leveraging the metrics above, value can be placed and impact measured of resolving bugs and paying back debt to achieve strategic goals. Be sure to measure improvements and investment against the goals as it surrounds bugs, and make it known when the team has an Extermination Hack Fest that resolves 15 customer found bugs which will improve our positioning on customers paying ongoing maintenance.

These are the four I’ve seen.  What have you used to get over the tug-of-war between new stuff vs. bugs?

Five Simple Guidelines to Agile Metric Bliss

in Agile/Agile Engineering/Project Management by

Over the past couple years, I’ve had the opportunity to work with many great teams in many industries. I often work with teams and their managers to generate reports. In doing so, I quickly realize that although teams may be working to adapt and leverage one of the frameworks that fall under the Agile moniker, they are not yet adopting or clearly understanding the Agile Principles and Values. This comes through clearly when we look at the kinds of reports people are using.

kittenI’ve seen dashboards that compare multiple team’s velocity. Or, the classic utilization report that shows time worked by team member. Or, the quality reporting that focuses on who versus what. And then there is the singular snapshot that represents percentage of backlog done – doesn’t sound that bad until you have a manager have kittens because the percentage is not what as expected.

Now, I have to admit — I’ve made all these reports before and used them myself. Sometimes the purpose of the report had an intended outcome, but my best intentions sometimes resulted in gamesmanship of the numbers or fear by the team and in one case, a team member pulled me aside worried that he may be culled.

Let’s face it, all metrics and reports can be used for bad. But what do you need to do to create good metrics? There are some great resources all over the internet that help answer this question, but let me give you my top five things you can do to make your metrics effective while fostering an agile environment:

  1. Make them Transparent. This is obvious, but often I see people create reports and don’t share them. I get that there are some reports for “their eyes only”; however, in most cases, if not all, unless it has salary information — make the reports visible to everyone – the Team, Stakeholders, Managers, and even Customers.
  2. Make them Visual. Use charts, shapes, colors, and or pictures over a table of figures. We do this for three reasons – easy to read, reduces the likelihood that people focus solely on outlier values, and in many cases — creates conversations. By the way, use colors wisely — just like words, colors mean stuff.
  3. Follow the Trends. Goes hand-in-hand with visualize — a good metric should be informative provided indicators that make it easy to see if the needle is pointing up or pointing down. Trends generally allow you to decide if what we are doing is good or bad, and reduce snap decisions.
  4. Make them Relevant and Timely. There are the out-of-the-box metrics — burn downs, cumulative flow, burn ups, cycle time, and or velocity – that should be maintained on a daily, weekly, or iteration basis — updating them in arrears does no good. This is the same for all agile metrics. Since the goal of any metric should be to continuously improve in some way, reports/metrics that are created or updated weeks or months after the fact does us no good. And, couldn’t we better utilize the time and brain power on something current.
  5. Have a Purpose. Every report or metric needs to be leveraged for importance. If you cannot answer two questions about a report or metric, maybe you should stop spending time and money to create the report. First, why are we creating this report? And, second, what will we do if the report is indicating a need to adjust or change?

Now, these are my five simple (and in some cases, general) guidelines – what are your’s? Do you have any suggestions?

Always keep in mind …

Working software is the primary measure of progress.

Continuous attention to technical excellence and good design enhances agility.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.Agile Manifesto

Go to Top