Tag archive

development

Words Mean Things – Inspect & Adapt

in Agile/Project Management/Teams by

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

In case you weren’t aware, this is the 12th Principle of the Agile Manifesto and it is often translated into “inspect & adapt.” Of the twelve principles, this is definitely the one that everyone can easily relate to. The team should look at what they are doing, look at how they are doing, and adjust. This is primarily for the team and I would argue that it’s mostly about the process (and maybe people stuff), but it could be around the product and or project if we are doing this in respect to a specific release or even the outcome of the sprint.

With Scrum, there is a ceremony (a.k.a. meeting) that is called a Retrospective. Other frameworks and processes have adopted the spirit of this meeting and there are a bunch of creative ways to conduct the retrospective. If they are kept fairly informal, transparent, and candid — then they can be hugely valuable — especially when they are actionable.

But this blog is not about the retrospective, instead it’s about the terms and maybe even way we speak of the concept “inspect.”

inspect. v. To examine critically or carefully; especially, to search out problems or determine condition; to scrutinize.

If you’re development shop is worth its salt, then you are constantly inspecting. Let’s face it, the feedback loop with following iterative development, using continuous integration, employing automated testing, and on a cross-functional team is really tight. This means that we are constantly re-digesting information from our feedback loop — so inspection is constant.

photodune-3550517-innovation-sI propose this, instead of “Inspect and Adapt”, shouldn’t we “Innovate and Adapt.” Now I cannot take credit for this change of terms, I was driving home one day from the office and I heard a post-season interview with the Atlanta Falcons’ head coach Mike Smith. He was talking about the fact that the team has reviewed all the tape from the year and now it’s time to innovate and adapt. He went on to say that seeing one’s issues and or challenges is not enough, they have to find ways to beat the competition and be better — that requires innovation.

innovate. v. To alter, to change into something new.

So instead of simply looking and digesting, let’s imagine and innovate. Once we innovate, we adapt the new ideas to our team, we continue inspecting our feedback loops, and we continue our innovation.

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

Pondering the Agile “Don’t Know” Methodology

in Agile Engineering by

DontKnowMethodIf you haven’t already heard the buzz, the VersionOne State of Agile Survey 2011 is now out and it is packed full with some great information.   The survey is a helpful resource to quantify what people are doing and the value they have realized or have not realized through their particular agile implementation.  As part of teach agile and speaking to the delivery methods used, I often reference the pie chart that shows the Agile Methodology Used and I updated my training materials with these latest results.  One thing really jumped out at me and made me go, “huh?”  That was that 8% of the respondents answered “Don’t Know” to the question of “What agile methodology do you use?”  That is roughly 500 of the over 6,000 respondents.  And like any good agile metric, seeing this only made me ask questions and hypothesize as to why that many folks answered “Don’t Know”.

The first though I had is training.  Yes coming from a guy that does coaching, that is the first thing I thought of.  But not for the reasons you may think.  If you think about it, the amount of teams applying agile climbing the blade of the hockey stick and as someone who has seen the benefits in product outcomes and overall organizational morale – this is great!  But, the challenge is with adopting agile it does require training the team members so that they, the TEAM, can make the transition successful and help adapt, adjust, and evolve the methods used to fit their development environment.  In Agile, the TEAM owns the process and the TEAM are empowered to make it successful.  This is much different than traditional project management where you can focus training on just those folks in leadership positions and the project managers.  The team just needs to know where to report time, and know how to write up their status reports.  So, if the team has not been trained on what agile is and the surround methods and processes, then I can understand when you ask them “Do you do agile?”, “Yes”, “What agile method do you use?”, “I don’t know.”

The second reason I can think of why folks answered “Don’t Know” is that they are leveraging multiple concepts from the various methodologies – including agile and traditional project management.  The survey did allow folks to answer “Hybrid” (9% of respondents answered), but in my discussions with teams lately – the application of Agile principles is the beginning focus with the adopting and adapting processes is much more flexible.  Teams are starting with one method and morphing to another, and in some cases leveraging a little bit from everything.  This approach can be good and bad, depending on the maturity of the team and the ability to continuously improve.

Besides the answer of “ignorant blissfulness,” the only other thought I had for the “Don’t know” response are those that work at organizations that have heard about this Agile thing and decided that they will become Agile.  So they leveraged Find and Replace to put the word Agile in place of whatever methodology they were using before.
So, what are your thoughts?  If you participated in the State of Agile Survey this year, why did you answer “Don’t Know”?

Go to Top