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.

Effective Agile Teams Are Proactive

Leave a reply

Proactively addressing risks is one of the major strengths of Agile methods. Not only do Agile teams have “spikes” to try to eliminate technical risks, but effective Agile teams have a mindset of eliminating a wide array of risks.  Here are some examples of ways risk is proactively addressed in Agile environments:

If a technology approach is of concern, we do a design spike and find out quickly if the approach isn’t feasible.

In Scrum, the retrospective is an explicit opportunity to look for ways to continue to improve, not resting with “we’re good enough”.

The “test first” approach is a proactive approach to quality.*

If the budget gets cut, we have working software created, not merely the requirements document, design document, and a pile of untested code.

The description of “Be Proactive” in the 7 Habits is “Proactive people take responsibility for their own lives. They determine the agendas they will follow and choose how to respond to what happens to them.” I don’t think I’ve seen an Agile book put it more succinctly. This excerpt could easily be rewritten for Agile teams: “Proactive [agile teams] take responsibility for their own [work]. They determine the agendas they will follow and choose how to respond to what happens to them.”

The Agile Manifesto’s 12 Principles has three in particular that stand out to me as having proactive risk mitigation components to them. These three are:

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

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

So, what do you do if you are on a team that has not embraced their responsibility to be proactive? Here are a couple of suggestions:

Consider whether or not your team has the trust necessary to be comfortable identifying risks. I suggest reading the book “Overcoming the Five Dysfunctions of a Team: A Field Guide for Leaders, Managers, and Facilitators (J-B Lencioni Series)“. This book is a follow-up to the book “The Five Dysfunctions of a Team”. The “Overcoming….” book offers specific activities  and suggestions that help address the dysfunctions identified in the earlier book.

Is the team able to communicate in a high bandwidth mode? If risks are getting lost in low-bandwidth communication, consider moving to a collocated room. Eric Landes authored a DevX article entitled “Team Rooms Breed Highly Productive Agile Software Development Teams“.  FYI: You will have to register to read the article.

Model proactive behavior. One of the best ways to show that something is important is to do it yourself.

 Encourage your teams to be more proactive about their work, and I believe you will find that good things follow.

*See the “Being Proactive – Getting to the Triangle of Happiness” blog about testing as it relates to happiness on a blog by Daniel Wintschel and humandoing software.

7 Habits and Agile Teams (Part 1)

Leave a reply

Overview

This blog introduces a concept that I will build on in subsequent entries.

Perhaps Stephen Covey’s most popular contribution to personal performance management is the concepts he shares in his book The 7 Habits of Highly Effective People. Long before I heard about Agile, I was part of a professional services company that had Franklin Planner training as standard training element for its employees. I still remember the instructor’s name, Rory Aplanap; a name like that is easy to remember. Rory taught the class with enthusiasm, articulating the principles and the practices that the 7 Habits book lays out. He also taught us how to use the Franklin Planner system to support the 7 Habits.

For those who are not familiar with the 7 Habits, they are:

  1. Be Proactive
  2. Begin with the End in Mind
  3. Put First Things First
  4. Think Win/Win
  5. Seek First to Understand, Then to be Understood
  6. Synergize
  7. Sharpen the Saw

I see some strong parallels between the 7 Habits and high performing Agile teams. Here is a quick preview of some of the correlations I will expand upon in future posts:

Be Proactive – Teams are responsible for themselves and their work. As one example, this behavior manifests itself in teams making iteration commitments in Scrum and team members stretching beyond their traditional roles to help realize that goal. Teams decide how they are going to function and how to respond to stimuli from both within and outside their team.

Begin with the End in Mind – This concept is present in planning that begins with a product vision, and is then unfolded to become releasable increments, stories and tasks. All this work takes place in the context of some shared vision that the team is working to bring into reality.

Put First Things First – We strive to ruthlessly prioritize, and to maximize the amount of work not done.

Think Win/Win – The objective is to find a path by which multiple parties meet their objectives. It is not about one side winning and the other losing.

Seek First to Understand, Then to Be Understood – For an Agile team, it is not about blindly following along in a task list that somebody has created for you; it’s about really understanding what is needed, and then sharing your perspective and concerns.

Synergize – Think about the collaboration between the Product Owner and the Team that results in a solution that is better than if the parties had worked independently.

Sharpen the Saw – This might be in the form of learning new engineering practices, having time to investigate a new and interesting technology, or simply celebrating as a team.

As I mentioned a the outset, this is simply an overview of the topic, and I will expand on it further in upcoming entries.

FIRST Lego League Challenges – Against the Odds

Leave a reply

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

I’ve spent the last 7 or 8 weeks coaching a group of 6th through 8th grade students as they prepared for the Regional and State competitions of FIRST Lego League. FIRST Lego League combines research, technical, and teamwork aspects into a really great contest. I’m going to take a minute to share how my co-coach Dr. Joshua Enszer captured our pretty challenging season. Despite the challenges, the team members have had a great time. Both teams at LaSalle Intermediate Academy had a good showing at State competition, and one of our teams progressed to the state level of competition.

This is how we got to where we are:

“On October 11, I received a phone call from a parent at LaSalle Intermediate Academy. She had been calling people who knew people in search of a coach for their Lego League team. They had one parent, Dan Neumann, committed to coaching, but needed another coach in order for the program to exist with the school’s two teams. Already a month behind in the season, parents were scrambling to fill this void so that the children could participate in Lego League this year.

Two days later I was in contact with Dan, another newcomer coach. We had no idea what we were getting into. LaSalle had historically performed well at competitions, but they’d also had the same successful coach since this program started! I personally had not heard of this program before this year. We read over the coach’s manual and scoured the websites and arranged for our team to meet for the first time on Friday, October 15, with five weeks to regional competition.

That Friday – and the following week of meetings, actually – was spent getting students (some with past experience, but largely not) to know one another and to set up the tables for this year. Veteran Lego League students brought new students up to speed on the aspects of the competition from day one – the research project, the programming challenge, Gracious Professionalism. It took three meetings just to construct the pieces for the programming table and to select a research topic. Four weeks to competition.

With the table ready for practice, students found the school’s NXT kits, evidently untouched since the year prior. It took no time to realize two things: one NXT’s display was no longer functioning, though it still had the capability to run programs; teams had never used light sensors and only one was to be found among the school’s supplies. We put in an order for more sensors and a replacement NXT as soon as we could. The team soldiered on with what equipment was available, and team mentors – previous Lego League participants now in high school – came back to help support the new students with their research with mere weeks left.

The students never gave up. We met three times—seven to eight hours—a week for the duration up to the regional competition. The new equipment came in and functioned perfectly. And then, the day before the regional competition, just an hour before we were to pack up and prepare to leave, the hard drive on the programming computer crashed. A student took it home to his father, who spent the evening retrieving the data, and miraculously, had it for us the next morning. We have doubly backed up everything since.

Harried, but determined more than ever to give a good showing, the team performed as best they could at the regional competition. Things did not go entirely as planned, but the students were not down. As the judges computed final scores, parents watched as our students lead a number of people in some games and dances. And after an interminable wait, the judging was announced, and our team placed in the regional competition.

The team has been imbued with a drive to succeed all season, and this placement only tempered their resolve. With a week to go to the state competition, the repaired computer bit the dust entirely, but files were securely stored elsewhere. Programs have been improved and expanded, the presentation script refined. Regardless of the result at the state tournament, these students have already survived a late start, rookie coaches, faulty and missing equipment, and two computer crashes. They’ve already beaten the odds to get here. Who knows what is next…? I wouldn’t underestimate them.

Josh Enszer ”

Thanks, Dr Enszer, for describing the situation so accurately. I am looking forward to taking this year’s lessons and returning to coach next year, if possible.

Here is a video of the robot trying to solve one of the challenges. We finally get consistent results toward the end:

 

Refactor (Don’t Rejactor) Your Code

Leave a reply

I believe that today’s team retrospective may have contributed a new term to the Agile lexicon: Rejactoring

While “refactoring” is the agile-embraced practice of improving the quality of the system without changing the system’s behavior, a “rejactoring” is a “refactoring” that “jacks up” the object of the refactor.  When a refactoring goes bad, it becomes a “rejactoring.” Rejactoring the code results in systems breaking in unexpected ways and at inconvenient times.

Here are some suggestions on how to avoid rejactoring your code:

  • Improve the code’s structure in a series of small increments, not one big change.
  • Have tests defined that will that give you quick validation that you have not inadvertently broken the current functionality.
  • Separate functional improvements from the refactoring effort. Combining a refactor with functional improvements is simply building new features, not a true refactor. Be careful not to bastardize the practice of “refactoring.”

For further reading on refactoring, check out Martin Fowler‘s book, Refactoring: Improving the Design of Existing Code as well as the site Refactoring.com.

So, What’s the Point?

9 Replies

One of my teams been involved in a bit of a discussion as to whether or not defects in the product backlog should be sized using Story Points, just as we size stories. Mike Cohn has a very good blog about “Story Points for Bug Fixing.” As I read his post, I believe it is specific to the scenario where a team has inherited a set of defects from a prior release or a legacy product that they are going to attempt to work through in the midst of delivering new features. Mike’s recommendation is that defects be sized, much like stories would, and that the resulting completed work would count toward the team’s velocity. I agree with that approach. I believe the scenario that we’ve encountered is a different one, and thus a different approach may be more suitable. The scenario I would like to explore is one in which defects found in the current release’s earlier iterations. Should those defects be sized and be included in the team’s velocity?

Consider a scenario where the features set to be delivered consists of 100 points of work, and that the team’s average velocity is 20 point per iteration. The figure below shows what a release burndown might look like under these conditions. Prior to iteration 1, there are 100 points of work to do. At the end of iteration 1, we have completed 20 points of work with high quality and there are 80 points remaining. Finally, at the end of iteration 5 the backlog has been reduced to zero*.  The burndown in this scenario is “Backlog Points Remaining after Iteration – Scenario 1”

This burndown shows the points remaining after each iteration is complete. Each iteration, the team completes 20 points of work on stories that are in the backlog.

In another scenario, we identify defects from earlier iterations, size them, and include them in the iteration’s velocity. So, in scenario 2, each iteration still shows a velocity of 20, but the burndown does not reach zero after the five iterations are complete.

This burndown shows the points remaining after each iteration is complete. Again, the team completes 20 points of work each iteration.

Without the proper visibility to the information feeding this chart, it appears that the product manager is growing the backlog. However, if you were to decompose the velocity into its constituent points (illustrated below),  you see that in the second scenario the contribution of defects to the team’s velocity grows throughout the release cycle. The assumption that the effort put toward defects will grow is reasonable; if there are defects being introduced early on in the release and nothing changes to address the root cause, the defects will continue to be introduced and their contribution will become more and more significant. Without transparency to what made up the velocity, the team can feel that they have executed with their ‘expected velocity’ and the product owner can feel like she is getting asked to make unreasonable concessions due to quality problems. Do you think it is reasonable that the product owner would remove scope because the quality of earlier deliverables was not high?

This view shows the points that were dedicated to stories in the backlog compared to points assigned to defects.

So, what to do?

I do agree that bugs from prior releases should be sized by the team and prioritized by the product owner, much like a new story. In that case, defects from prior releases would be included in the velocity, and the product owner could determine what new features could be completed if work toward resolving legacy issues was suspended.

If defects introduced in earlier iterations are going to be fixed in subsequent iterations, their contribution to the team’s velocity should be made big and visible. Only if the information is visible will it get the proper attention so the team and product management can work to figure out the root cause of the defects. If the team is not going to make the effort put toward resolving defects visible, I would suggest that it would be best to not size the defects and to merely let the ongoing reduction in team velocity be the canary in the coal mine. Unlike the scenario that Mike spoke about, the team cannot reasonably suspend defect resolution to deliver additional features.

Lastly, if the team’s anticipated velocity includes an allocation to fixing defects that are yet to be introduced, this needs to be accounted for as part of release planning, as well.

Ultimately, it is critical to identify the root cause of the defects and to address the root cause. Without addressing the root cause, we are left with an ever-increasing allocation of time to resolving defects that we are introducing as we build new features.

Conclusion: Sizing defects that are introduced as part of the release that you are currently working on can produce a misleading velocity. If you do want to size defects and have them contribute toward the velocity, segregate the points from Defects and Stories so that the effort toward each becomes plainly visible.

Footnote:
*For the sake of illustration, I have simplified the scenario. Indeed, there is often some variability in velocity from one iteration to the next. This scenario also assumes that the product backlog is constant throughout the five iterations.

Is Entrepreneurship Genetic?

1 Reply
Genetics Portal Logo

Image via Wikipedia

I just finished attending the last session in a great series about entrepreneurship that was offered by Indiana University South Bend. While I was filling out an evaluation form for the series, a student happened to sit down next to me to fill out his survey. I was surprised when the young man offered his feelings, those of disappointment, that the series was filled with people whose families had owned businesses. In addition to that, he continued, Michael Kubacki,  President and CEO of Lake City Bank and former member of the Federal Reserve Bank of Chicago,  upset this person so much that he had to leave the room. To say I was dumbfounded is an understatement. I was so impressed with the speakers and their accomplishments that it was beyond comprehension that somebody would have such a diametrically opposed view. I responded with mere grunts. It was one of those moments that I wish I could back. It seems like a missed opportunity to perhaps share a different perspective.

Indeed, the Entrepreneur Lecture Series 2010 did contain a number of speakers that had family businesses or were children of business owners:

  • Mark Tarner, President of the South Bend Chocolate Company – his father was a chocolate maker
  • Amish Shah, President of Kem Krest – his father owns a successful business
  • Rob Bartels, Jr., President & CEO of Martin’s Super Markets, Inc – Martin’s was founded by a family member
  • Larry Davis , President of Daman Products – Daman Products was started by his father and he

I believe that there is most likely an advantage to being in a family that owns a business. As the son of a minister and a secretary, I can only imagine that being around people who own businesses exposes you to an abundance of knowledge about how businesses actually work (marketing, planning, product management, finance, etc..) that are not quite as accessible to other people. It is important to remember that just because some people may have an apparent advantage does not mean that the goal is out of reach for you.

This year’s lecture series kicked off with an inspirational lecture titled “Seize the Opportunity” from the South Bend Chocolate Company’s President Mark Tarner. Mark reminded the attendees that the United States is still “the land of opportunity.” Mark is an extremely hard worker, constantly investing time in the company. Mark emphasized planning as one aspect of seizing the opportunity, but ultimately you need to take action on your plan. Apparently, the gentleman next to me this evening missed that part.

Amish shared the impact of the economic downturn on his company and how Kem Krest has had to adjust.

Rob shared that Martin and his wife, the supermarket’s founders, subsisted on the ‘shrink’ of the store. The ‘shrink’ is the food that is not good enough to sell any more, but is still good. Think brown banana…

Larry Davis shared his experience about the hard times starting his business. It was about a decade before their business was really thriving.

Each of these people, and most of the other presenters, had to overcome adversity before they became successful. There was a common theme, as well, that just because you were once successful does not mean that you now sit back and rest.

In 2009, I went to Chicago to hear Molly Fletcher, agent to Tom Izzo, top female sports agent, and author of the book “Your Dream Job Game Plan, 5 tools for becoming your own career agent”, speak to a group of Michigan State University, Northwestern University, and Ohio State University alumni. Molly shared some keys to what she called “your dream job game plan.” I believe the advise is equally applicable to entrepreneurs:

Have passion and style
Be fearless
Have a game plan
Execute flawlessly
Manage your choices

Lastly, and probably most importantly, Molly suggests surrounding yourself with other “five tool players”, those who are going to help you become better. I believe that this  last point would be particularly valuable for this man that spoke to me this evening. Being  jealous of the presenters is not going to move you forward. If you want to be like those people, reach out to them. Build a relationship, and try to learn from them. The speakers are entrepreneurial, and not only have been successful in business themselves, but are excited by the prospect of others pursuing their business dreams as well.

Would I have changed this man’s mind? I don’t know. I do hope that he realizes that what the future holds for him is largely within his control. Jealousy or disappointment over another person’s perceived advantage will only distract him from doing great things himself, as it will with any of us.

Entrepreneurism isn’t a matter of genetics, it’s about being fearless, having a plan, and executing.

Lastly, thank you IUSB for hosting the series and opening it up to the public free of charge. I look forward to next year’s series.

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]