Category Archives: Project Management

D-Day Reflection of an Agile Coach

Leave a reply

For some reason, I got to thinking more about D-Day this year than previous years. Both my grandfathers served the war effort, as did my grandmother Neumann. Intending no disrespect to the contributions of the Neumanns, my thoughts have turned to my Grandpa Dubie. He rarely spoke of the war. Much of what I know comes from a single conversation. I’m not sure why he felt like sharing that day, but I am glad he did.

Grandpa didn’t storm the beaches of Normandy on D-Day. As the story goes, he entered Europe the day after, by way of the beaches. His brother also served in the US Army, but with the war going on, he had no idea if his brother was part of the D-Day invasion. As he came ashore, he said he felt like he wanted to turn over every dead service member he passed, fearing that one was his brother. I can almost hear the emotion in his voice as I recall the telling of his story.

I don’t know how long after entering Europe that Grandpa earned his purple heart. He and his partner were digging their fox hole that day. It was Grandpa’s turn to dig, and he went into the hole head-first to make more room for his toes. That’s when the shell landed. The next part of the story was his flight back, calves badly wounded, and the army medical personnel removing the maggots that were being used to clean out the wound. His partner, and most of his squad, did not make it back. Had he not been burrowed into the foxhole making more room for his feet, he would have returned in a casket.

While he survived the physical trauma of the war, the emotional scars remained. Forty-five years after  returning to the US, he related a recurring nightmare; walking through a barn and having a German soldier jump down from the hay loft and repeatedly stab him in the chest. Grandpa said that he’d awoken pounding himself in the chest. I can only imagine the terror that must follow so many of our soldiers after their service.

So, what’s the point of this? First and foremost, it’s to share the story and honor just one of the millions of service members. Second, I think it’s important to maintain perspective. I have the pleasure of working as an Agile Coach. I work with people whose biggest complaint might be that they don’t have as much autonomy as they would like. Maybe their manager acts more like a boss, or the pace of their work doesn’t seem sustainable. Yes, those are things that can be improved. But, in the grand scheme of things, remember to be thankful that you’re not being shot at on a daily basis. And for those service members that do put themselves in harms way on a daily basis. Thank you.

 

Arduino Ultrasonic Sensor

Leave a reply

In addition to Agile Coaching, I enjoy projects that require building skills. While working with a new Arduino Ultrasonic Sensor from RadioShack, I came across a question on the “Find your way with the untrasonic sensor” page. Below is a photo showing how the I chose to hook up the wires. Hopefully it helps others…

Arduino Ultrasonic Sensor

Arduino Ultrasonic Sensor

The yellow wire is connected to Digital Pin 7, the blue wire to the 5V pin, and the orange wire to GND.

When connected this way, the Serial Monitor for Arduino showed expected output (a distance to an object). When I disconnected the yellow wire, or had it in another slot, the Serial Monitor would show “0” for the distance.

We Don’t Have Time to Automate the Code!

2 Replies

Picture this: You’re planning a sprint, going over stories in the Product Backlog, bringing high priority stories into the Sprint Backlog, and working to identify what is required to deliver the stories. The Product Owner is present, making sure that the team understands the acceptance criteria, and the ScrumMaster is facilitating the session, helping ensure that the team doesn’t overcommit. Things are moving along smoothly.

As the team begins to figure out what it takes to deliver a story, a team member says:

Some rights reserved by ginatrapani

“Well, we can figure out the steps the system will have to perform to complete the business logic. We also know what data table the result needs to go into. The Product Owner really wants this feature, but we’re not too familiar with the new programming language we are using and it would take too much time to figure it out. For now, we will put the logical steps into a Word document and have a developer follow the steps in the document and manually enter the result into the system we have to interface with.”

That would be absurd! No developer would ever utterer that in real life. The story can either get coded to meet the acceptance criteria within the desired timeframe, or it cannot.

Now, if you take that previous sentence and change it a little bit:

“Well, we can figure out the steps the system will have to perform to complete the business logic. We also know what data table the result needs to go into. The Product Owner really wants this feature, but we’re not too familiar with the automated testing framework we are using and it would take too much time to figure it out. For now, we will put the logical steps into a Word document and have a tester follow the steps in the document and manually enter the result into the test result matrix.”

Somehow, the “test” version of that paragraph isn’t only acceptable to a lot of teams, it’s incredibly common to hear. “We don’t have time to automate the tests.”

In reality, you don’t have time the luxury of not automating your tests. Manual testing isn’t sustainable; it is too expensive and it is too slow to execute all the logic present in your application. Because manual testing is not feasible, the buildup of untested code in your system present the biggest risk to almost any software development effort. (James Grenning recently articulated a strong case for why this is so at a recent Chicago Agile Project Leadership Network meeting.) That risk may not manifest itself today or tomorrow, but not too many versions down the road your team, your application, and your business is going to hit a brick wall of poor quality.

Automated testing cannot be optional. It’s the team’s responsibility to make sure that automated tests are being created. You don’t have to be perfect to get started; just start during your next Sprint. Next, inspect and adapt. Learn from others, get training, and make the investment. Perhaps you “complete” fewer features by not investing in automation, but remember… you would not call a story “done” if the code is not automated, so don’t call it “done” if the tests are not automated.

Failure or Success

Effective Agile Teams Begin with the End

4 Replies

Failure or Success“If you don’t know where you are going, any road will get you there,” said Lewis Carroll. Not only does this statement apply to individuals, but also to teams. In either case, you might not like the destination when you get there.

Stephen Covey’s second habit is “Begin with the End in Mind”. Before you can effectively create the physical manifestation of the product you want to create or the team you want to be, you have to first create a mental representation of that end state.

One exercise he proposes for helping to clarify what is supremely important to you is to visualize your own funeral. When you visualize your family, friends, or coworkers speaking about you after you have passed, what would you want people to say? As helpful as this visualization exercise can be for individuals to recognize what is important in their lives, it is also important for teams to determine what is important to them.

If an article were written about your team and preserved for the future, what would you want people to know about your team, about how you treated each other, and the way you went about your work? To help determine what is important to your team, consider your team’s ultimate goal. What do you want people to say about you, your team, and your work. Consider your teammates, your Product Owner, your stakeholders, and your customers. What about your functional manager? Consider involving your stakeholder community in the discussion.

Going through such an exercise can result in identifying a common view of what the team wants to become and how they want to operate. Without agreement on what the team values, the urgent demands of the project can keep you from becoming the team you need to become. Symptoms of teams without a compass may be that your team becomes myopic, focused on creating features to the detriment of sustainable pace or maintainable code. Alternatively, your team could become paralyzed by analysis and architecture debates, not recognizing when the analysis is sufficient to allow it to move forward.

To create your team vision is to “begin with the end in mind.” It is more than an elevator statement that captures the 30-second pitch for your product, and it is also more than a list of user stories that you intend to complete within a particular timeframe. What you want to distill from this exercise is a set of principles that can inform the decisions that you and your team will have to make through the course of your work. Take the information you collect and use it to create a mission statement for your team. When creating your mission statement, ensure the involvement of all team members; perhaps have a facilitated discussion led by somebody from outside the team can help ensure that all voices are heard. As Mr. Covey puts it: “No involvement, no commitment.”

Make your mission statement visible in your team room, on its wiki, give printouts to each team member, and anywhere else you feel is appropriate. If somebody is violating the mission statement, inquire about the deviation and determine if the mission statement has become outdated or if the behavior is perhaps not correct. Include a review of the mission statement as part of your retrospective.

Remember, if you are on an team and don’t know where you are going, you won’t get anywhere you want to be. Keeping the end in mind and using the mission statement as a team compass can help the team stay on track toward its desired goal.

Michiana Agile Practitioners – December Meeting

Leave a reply

I just posted a new notice for the Michiana Agile Practitioners gathering at Hacienda (4650 Miami St, South Bend). The meeting will be on December 6th at 5:30 PM, and we are typically done by 6:30 or 7:00. We meet in the patio area, which is closed in and comfortable, even in December. Topics for discussion range from process to engineering practices, and are not limited to one particularly technology stack or another. It’s more of a community than a “meeting, ” so please join and don’t feel any pressure. There is a posting on LinkedIn, so feel free to join the group and participate in the discussion.

Motivation 3.0

1 Reply
Cover of "Drive: The Surprising Truth Abo...

Cover via Amazon

 I just completed listening to the audiobook version of Daniel Pink’s book Drive: The Surprising Truth About What Motivates Us. This book follows the evolution of motivation from its biological roots in self-preservation (dubbed “Motivation 1.0”) to the carrot-and-stick incentives of seeking reward and avoiding punishment (“Motivation 2.0”), to what research is finding to be a higher motivation, labeled “Motivation 3.0”.

Earlier versions of motivation were responses to external forces. Unlike those earlier revisions of motivation, Motivation 3.0 is characterized by a human desire for a sense of autonomy, a chance to become masters of our particular craft, and to be driven by a purpose that is beyond ourselves.  The book progresses from sharing studies that have indicated that “carrot and stick” motivation only yields its desired results for a subset of repetitive, non-creative activities,  to a discussion of intrinsic and extrinsic types of motivation. For people who are intrinsically motivated, their motivation is fostered by their sense of autonomy, mastery, and purpose.Autonomy can be expressed in various aspects of our work: 
  1. The task itself
  2. The time in which we do it
  3. The technique we apply to the work
  4. The team with which we work

Different people will value autonomy over various aspects of their work more than others. I may most value autonomy over technique, and you may value autonomy  over the time in which you elect to do the work most. A couple of items in this discussion resonated with me:

  1. You can have autonomy, yet still be interdependent.
  2. Accountability still exists, even when there is autonomy.

Mastery is all about working toward a high level of execution.

  1. Mastery is a mindset: It requires a dedication to performing activities that will help us become better.
  2. Mastery is a pain: Becoming a master requires repetition over a long duration, like 10 years.
  3. Mastery is asymptotic: You can get closer and closer to mastery, but never be truly perfect.

Purpose is all about having a cause that goes beyond ourselves. The audiobook version was excellent, allowing me to cover much of the book while I was performing activities that I could not do while reading the book. For folks in St. Joseph County, Indiana, the audiobook is available for checkout on iPod at the St. Joseph County Library. You can use the library’s site to check for availability. Like some other audiobooks I have checked out, I suspect I will be purchasing a print copy of this book soon. The paper copy will serve as a convenient reference. 

There is a video that shares some of the book’s points, but in my opinion is a far cry from spending the time to experience the entire book, either in audio or print format. However, the video will take about 10 minutes to watch, the audiobook is about 6 hours long. My recommendation is that you watch the video, then go get the book. 

 [youtube=http://www.youtube.com/watch?v=u6XAPnuFjJc]

Marathon Racing

2 Replies

It seems that sport analogies are often used to try to describe what happens on project teams. Software development efforts are equated to a race. As one who dabbles in foot races and triathlon, I couldn’t help but start to think about analogies between projects, teams, and those sports.

The sport analogy that most often comes to mind for me is the sport of marathon running. I have raced in four marathons; Chicago one time, and Detroit three times. Like software projects travelling the marathon distance of 26.2 miles requires a nontrivial investment of time and energy for preparation and execution. Also, to complete an endurance event like a marathon, there are several distinct phases.

This article lays the foundation for some later posts about specific aspects of the race analogy.

Wait for it…

Leading up to the race, I think about strategy, have written down my expected pace, and am anxious for the race to start. Despite a desire to just start, you can’t start until it’s time. Racers wait in holding pens and chat with one-another, loosen up, and anticipate the starting gun. Ceremony marks the approaching start. There is music, weather updates, last-minute course information, and ultimately, the National Anthem.

3, 2, 1…

Once the race commences, there is even more excitement. Crowd support is typically strong at the beginning of the race. The cheers of the crowd lift the spirit as you leave the starting pens and move out onto the course. The race has officially begun.

The first half

The first several miles are pretty enjoyable. If I’ve been realistic about my pace, it’s pretty easy to meet or exceed the pace that I set out to run. The miles tick away, 1, 2, 3, 4… I feel good. The excitement of the new race is still there. Aid stations are available, and despite not feeling like I “need” fluids, it’s a good opportunity to momentarily slow down, hydrate, and check my pace. Then, back to running…

As the middle of the race approaches, I continue the mental math, doubling my mid-race time and starting to get a better feel for what finishing time I expect to have. Thirteen miles down, thirteen to go. If I have prepared properly for the race, I still feel good.  I appreciate the aid stations more and more as the race goes on. In addition to the liquid, it helps to take in a little bit of solid food as the race goes on.

The next quarter

Somewhere over the next six to eight miles, the race starts to feel like real work. The legs start to feel tired, and the anticipation for the next mile-marker builds. It can become a challenge to keep up the pace from one mile to the next. The support of the crowd often thins during these miles. The encouragement that was present at the start and middle of the race becomes less frequent. As mile 20 approaches, the race becomes a mental game, knowing that my training has prepared me for the full marathon distance.

The last quarter

The miles in the low-twenty seem to be the most challenging. The effort to continue increases, and it’s not unusual to have a burning sensation in my legs.  The amount of relief that the aid stations provide diminishes, and it becomes a struggle to go on.

It is also over these miles that the anticipation of the finish line builds. The purpose of all the training and all the previous miles has been for the purpose of completing the whole distance. It is also over these miles that it is encouraging to match the pace of another runner. What can be an individual event can transform into a cooperative game of mutual  encouragement.

The finish

The finish line is the ultimate checkpoint. There is celebration, review of the events that have transpired since the beginning of the race some hours before, and a realization that the most significant milestone of the day has been reached. Ironically, it is also at this point when the discussion of the next event crops up. The finish isn’t as much an end as it is a launch point for the next big thing.

Future posts

As I created this entry, I was tempted to digress into discussions of aid stations, multi-discipline events, sustainable pace, technical debt, and cooperative aspects.  Look for those in future posts. If analogies came to mind as you read through this, feel free to share.

A Scrum Presentation You Can Deliver

Leave a reply

So, you have the opportunity to deliver a overview presentation on Scrum. Creating slides sure can take a lot of work, especially if you want them to look good and flow naturally.

Fortunately, you do not have to reinvent the Scrum presentation. Mike Cohn has made a Overview of Scrum presentation available on his web site. The presentation can be customized and used under the Creative Commons license 3.0.

If you have the opportunity to introduce Scrum to an audience, save yourself a lot of time and energy. Check out the Overview of Scrum presentation.

Mike Cohn’s book Succeeding with Agile

Leave a reply

Mike Cohn is nearing completion of his latest book Succeeding with Agile. I downloaded and read Chapter 2, “Iterating Toward Agility,” earlier today.  I highly recommend going to www.succeedingwithagile.com and downloading whatever chapter is available at that time.

Mike Cohn has also set up a Yahoo Group to discuss exchange messages about his book, as well.

Manage your projects with more than GPS

Leave a reply

Driving with GPSWe were driving from South Bend, Indiana, to Chicago, Illinois, in May. My son was alternating between reading a book and watching the GPS as we traveled West on Interstate 90. With about 15 or so miles to go until we were got to the Indiana/Illinois border, the road was under construction. As I drove, there were lane shifts to navigate, concrete barriers on the lane shoulders, and pot holes that looked big enough to break a tire if you hit them at full speed. My son, glancing up from his book to look at the GPS screen, announced that we were going through Gary.  

 

As I continued to drive, dodging potholes and shifting lanes as necessary, I thought more about my son’s comment.  Obviously, a GPS can give you useful information to navigate, but it was no substitute for looking out the windshield and in the rearview mirror. The GPS doesn’t tell you about other cars. GPS can’t tell you about approaching emergency vehicles. And, GPS will not tell you about road hazards that seemingly come out of nowhere.

 

Just as a GPS gives useful information for navigating, IT project dashboards, burn down charts, and iteration velocity provide information you can use to navigate. These can tell you about the direction of your project and give insights about the speed of the team. They may even help you determine if your project is likely to be late, or not. However, if you forsake meaningful team interactions and observations, you risk hitting a project pothole or barrier that was not shown on the information radiators you use.

 

On projects, use information radiators. In addition to those sources, make sure to look beyond the dashboards. Interact with the team. Ask questions. Assess the risks. Hold your retrospectives, and make sure you know what your alternative paths are. Whatever you do, don’t do the project equivalent of following your GPS off a cliff.