I am absolutely honored to have been selected to serve as the Technical Program Chair for Agile2017. I have the further honor of managing the return of the Audacious Salon after its successful inaugural year.My first significant duty as Program Chair was to assemble a Program Team. For each track in my assign, I needed to identify a chair and co-chair to help define the track, recruit a review team, and ultimately select the track content.
Collaboration Contracts are a way of identifying who is involved in a decision and what level of decision-making authority each participant has. This isn't a delegation model where some individual is empowered and imparts unto others some fraction of their authority for a limited period of time. This is a collaboration model where all participants are equally empowered, but find consensus on all topics to be a suboptimal approach.
Dinner together as a family was a key part of how we raised our children and how we kept our family so tightly knit for years. No matter what you had to accomplish in a given day, you did your damnedest not to miss dinner. I often left the office, came home to share a meal, and headed back into the office.
There were no boundaries at the dinner table. There didn't need to be. We talked about everything.
I often find myself talking to people who are in the midst of a switch to agile and who find the change very difficult to get used to. They may be strong advocates, but their team just "doesn't get it". Through discussion, I find that many of them are attempting what I refer to as "Shock and Awe" agile. If you couldn't tell by the name, I consider this another agile coaching anti-pattern.
I read an article today that was posted on LinkedIn. I'm not going to link to the article. I'm not going to tell you who wrote it. I am only telling you about the article to set the stage for what I want to write about in this quick post.
In the article, along with "taking the best from Waterfall and Agile" and mixing them together into a "perfect methodology", the author, as a self-proclaimed change agent, suggested you should force implement all CMMI Level 5 developer practices at once.
I saw a tweet this morning that caught me off-guard.
If your software makes money it is good software by definition. Nothing else matters. #Agile ^ @SkankworksAgile — AgileFortune (@AgileFortune) July 23, 2015
It doesn't strike me as consistent with the type of thing AgileFortune usually tweets. My initial reaction was to reply via twitter, but didn't feel I could express my thoughts well in 140 characters or less.
Back in May of 2014, I attended ALM Chicago. I had the privilege of closing out the conference with my "Let's Start an Epidemic" talk. The second speaker of the day was Venkatesh Rao. This was his third time speaking at the conference and I quickly came to understand why they kept inviting him back. His talk was daring, extemporaneous, and insightful. There were many pearls in his presentation, but one thing he said in particular struck me.
Fist to Five (a.k.a. Fist of Five) is a simple tool for measuring level of agreement in a team. Often, this is far more expedient than discourse, even among those in agreement. Secondarily, it helps to overcome “silence means consent” for teams where this may be an issue. This is not a replacement for discussion, merely a way of getting a quick check to determine if more discussion is actually warranted.
I've long had an aversion to the phrase "Best Practices". As I started out writing software, I looked to my mentors and industry leaders to inform my decisions about how things should be done. If they shared their "Best Practices", I took them to heart. I wanted to be the best coder I could possibly be.
I saw a tweet this morning that got me thinking about a coaching anti-pattern I frequently see:
"Without knowing you, your Agile coach knows you use should start using stand ups, TDD and pair programming, etc. Taylor would be proud."
THE PRESCRIPTIVE AGILE COACH
The Prescriptive Agile Coach is armed with a reliable set of practices. The practices have been documented, vetted, and implemented successfully on a number of teams. They are inarguably proven. To the Prescriptive Agile Coach, those not following these practices are not truly Agile.
As an "agile coach" over the past several years, I've seen a lot of different techniques and approaches. I've been impressed with the ability of some coaches to slowly and gently affect change; sustainable, genuine change. And I've been dismayed at the number of coaches who trivialize the complexity of change to check-lists and notions read from books, but never tried.
This series covers some of the (anti-)patterns I've seen among check-list agile coaches.
Retrospectives are simple, but not easy. The general idea is to get the team together, establish a context, gather relevant data, develop insights, and decide what actions to take. Esther Derby covers the retrospective structure well in a slide presentation on her blog.
As a coach, I've gone into numerous environments with the intention of introducing agile. Of course, I always talk about the values and the principles. Of course, I try to help people to see that there is no one true agile. There's no prescribed set of practices that once followed earn you the agile merit badge.
At the same time, these teams need something concrete. What things can one do in order to set them on the path to "being agile"?
It was 1983 and I was in science class when I first heard the term entropy.
I don't recall if we were discussing energy conversion, heat as waste, or some other topic wherein entropy plays a part, but I do recall how profound the concept of entropy seemed to me. The notion that there was a lack of order, a lack of predictability, and a gradual decline into disorder resonated with me deeply.
I've been thinking quite a bit about estimations and our general obsession with getting them "right". After all, we need to know when the project will be done. And we need accuracy. Knowing the entire project will be done before the end of the third quarter isn't good enough. We need to know that the project will be done this month or this week or perhaps even on this specific day.
Refactoring: How does it fit into your Agile process?
We are in the midst of writing a new product, at this point the developers are realizing that some of the code should be refactored to improve performance and or clarity for ease of use. How do you fit refactoring into you Agile process? We have created separate backlog items for refactoring specific pieces of code. These backlog items are treated exactly like any other backlog item (meaning they have effort assigned and are committed to sprints by the team). What do you do when refactoring is necessary?
Have you ever been on a team where your velocity suffered wild variances? Maybe you ended up using a running average instead of yesterday's weather?
Have you heard phrases like, "Well, our velocity last iteration was 3, but our average is still 22"?
Have you ever heard the phrase, "Dude, we need to get this velocity stable."
Have you worked on teams where they took partial credit for done at the end of the iteration? Where maybe you'd split a card strictly on points and award some apportion to the current iteration and assign the remainder of the card to the next iteration.
Working with several clients, I see differing story formats. The format I see most recommended is "As a, I want, So that". The format I see most utilized is "I want". Isn't this the important part of the story anyway?
I think not. Let's look at the three components: As a, I want, and So that.
I really enjoy pair programming. It seems a natural process to me and I often wonder why it is that I like it so when others may not. Clearly, we have differing tastes and styles. I am sure that contributes to the joy (or lack thereof).
I've been watching others pair lately. And there is something I've noticed; pairing done well is conversation.
Journeyman Jones, a journeyman carpenter is called upon to train a team of aspiring apprentice carpenters at Gable Gates. On the first day, Journeyman Jones sees that the apprentices are all striking nails with the broad-side of the head instead of the intended business end.
A client was looking for a way to introduce code quality standards to their development teams. There had been a few meetings prior to our involvement. The prevalent line of thinking was to draft a standards manual for dissemination to the teams. This would consist of a comprehensive set of rules and clear specifications to which all teams need comply.
Davey concludes his post with the following paragraph:
"Keep your ears, your eyes and your mind open. If you notice that a group of people gets excited about something new, then figure out why. If you notice that something appears to be working well for others, then figure out why. If you notice an increasing stream of criticism on the technology you’re using, then figure out why. You’ll need information like this to make well-founded decisions about your future."
I was looking for a game that helped to emphasize the detrimental results of a focus on speed over quality. How such an approach had only a short-term gain and then proved to be more costly from there forth.
A recent article by Tobias Mayer has been getting a lot of attention. "The Scrum Compliance" is an accounting of why Tobias is moving on from the Scrum Alliance. This article is not the first on the ugliness that has become the Scrum Alliance.
Esther Derby put together a nice post on the importance of design for a web site in which she asks, "Are we aiming too low?"
Agile methods manage business risk. They can bring back enjoyment and pride in work for development teams. For the people who use our software, they make work life maybe less frustrating, because the software isn’t buggy, and maybe a little easier because the software does what it’s supposed to do. But I think we are aiming too low. Can we also make software a pleasure to use?
I read a post recently from teknophyl entitled "Motivating the Unmotivated". He asked me to read it and give him some feedback. I started a reply in the comments and realized this one was going to take some time.
I encourage you to read his blog entry. I am willing to bet it will resonate with most of you, either as a participant in a similar series of events, or at least as a witness.
This is a quick post. I just want to share a technique we've been using for initial story estimating. I first used this technique at ThoughtWorks when we were working on a project that required a lot of estimating. I think it came about because 1) we did not have any estimating cards immediately available and 2) that is the kind of place ThoughtWorks is. I later came to discover that the technique is not only fun, but it actually has a few additional benefits.