Wednesday, April 6, 2016

Don’t Let the Creep In

No, not the creepy zombie from the Walking Dead.  I’m referring to those extra features that can creep in and increase the scope of your project.  Combating feature creep and scope creep is a constant challenge for software teams. At 10X People we use the term MFR to help avoid scope creep and focus on what is important.

What is MFR/MVP ?
Minimum Feasible Release (MFR) and Minimum Viable Product (MVP) are two terms frequently used on software projects to indicate the minimum set of functionality that can be developed within a defined period of time and within a set budget.  Working within cost and time constraints requires that we focus on the features that deliver the most value to the customer.  As teams design and implement functionality it’s easy to slide down the slippery slope of including “nice to have” features.  Especially when customers are pulling you down that slope.

MFR is one of those concepts that is easy to say, seems straightforward to follow, but it can be difficult to put into practice. Differentiating the important features from the not-so-important  ones can be difficult. When there are strict deadlines or urgency to deliver functioning software, it becomes easier to identify features that can be deferred, and focus on the features that add the most value. The bells and whistles can be added over time if they warrant the cost of implementing them.

Challenging our customers to justify building features is part of our culture. Sometimes this can be misconstrued, and customers may think we are saying that we won’t ever deliver a feature. However, when we challenge the feature set we are merely enabling the focus to be on features that add the most value first.  All of the desired features get put on the backlog and implemented based on priority.

Separating the wheat from the chaff
So, how do we separate the “wheat from the chaff”?  On some teams, an MFR hat displays prominently on the story maps and storyboards. It’s there as a symbol to remind each other to challenge ourselves to justify the value of features. Sometimes we draw a line on our story maps and backlogs and put features that can be deferred below the line as we plan. Additionally, simplicity is a common mantra in our teams.  When things get complicated try to find a way to simplify it and then ask ourselves if the the simple approach is good enough at the point we are in within the project.
Let’s face it, software teams love to build and develop features. But, in the end a successful business relies on the right features being developed at the right time and the right cost.

Friday, August 21, 2015

Experimenting with Food and Lean Software

Sometimes our personal and professional lives become intertwined. In some cases our coworkers become lifelong friends. In the case of 10x, one of our software methodologies happened to sneak it’s way into our personal lives without us even realizing it.
At the start of this year several of our employees (and in many cases families and spouses) took on the whole 30 challenge, It is not a diet but an experiment with the foods we eat. You eliminate grains, dairy, legumes, alcohol and sugar for 30 days and then add them back in one at a time to see how they affect you.
So what in the world does this food experiment have to do with software and work? One of the 10x methodologies we practice is developing lean software. From the wiki the definition is “Essentially, lean is centered on making obvious what adds value by reducing everything else.” This definition maps directly to whole 30 for me.  We reduced all foods that might be psychologically unhealthy, hormone-unbalancing, gut-disrupting, or inflammatory food groups. Then we added back in what brought value for us. After all it was only for 30 days, we didn’t have to give up chocolate forever. We learned how these foods affected us and now we can make better decisions about what to eat, what not to eat, and what to eat in moderation. It was an eye opening experience.

Does it make sense to try a whole30 for your software development project?  What if you simplify, cut out everything and started with a very basic set of tools and processes. As your project went along and you missed something you had before you would know it was necessary and that it adds value to your project. Evaluate it and add it back in. My guess is many teams would find that some things they thought they couldn’t live without would end up not being missed. You may even find that the tool you thought was the most useful was taking more time away from developing the software than the value it was adding to the project. There will certainly be surprises around what is essential and useful.

- Written by Ronnie Ridpath

Tuesday, July 21, 2015

There Is No "I" in Team... or Is There?

The ‘I’ in team is only in the A-hole.

Have one on your team?

Symptoms of the A-hole

  • Concerned with only their tasks
  • Considers their work ‘done’ for a story when their task is complete
  • Moves to new stories of their choice
  • Feels some tasks to be beneath them

Who is the A-Hole? Look in the mirror. Most of us are at some time or another.

  • Feeling a deadline, you push “your stuff” into the build and it breaks.
  • Once your stickie is done, you pronounce yourself ‘done’ and move on the next story
  • You don’t see anything on the board to do so you:
    1. Pull in a story of your choice
    2. Work on things “not on the storyboard”
How to avoid being the A-Hole

  • Take the time to ensure your piece WORKS. It builds. The tests run successfully. Then check in your update.
  • Your piece works. Is the rest of the story done? Work with your story-mates to ensure the story completes.
  • Not sure where to get started on a story? Ask your story-mates. Everyone working in sync makes the story complete faster with better results.
  • Realize your priority is to the board and every team member owns every stickie. Consult with your team about where you should go next.

Nobody likes the A-Hole. No one should be one either!

- Written by Kayla Hahn

Monday, March 30, 2015

Common Mistakes # 6 - Overlooking Skillsets and Team Dynamics.

My son rows on a crew team. He practices 6 days a week for 4 hours a day.  When he isn’t rowing he’s frequently watching rowing videos; examining technique and evaluating strategy.  Initially, I knew very little about rowing. I realized that if I was going to communicate with my son, I had to learn more. So, I picked up the book “The Boys in the Boat” by Daniel James Brown.  It’s an amazing story about 9 Americans and their participation in the 1936 Olympics that helped me understand rowing, it’s intricacies and team dynamics.
The teamwork required just to get a boat launched is impressive. It is fascinating to watch nine teenage boys take a 60 foot boat from it’s rack onto their shoulders, walk it several hundred yards to the water and orchestrate a launch. Think of the teamwork required.  It dawned on me how the dynamics in a crew boat are similar to the dynamics of a software team.  Just like crew teams, there are winners and losers. All teams are not created equal with performance directly related to the people on the team (and equally important, how they work together).  

On an 8 man boat there are 9 positions,  8 rowers and the coxswain.  The coxswain guides the boat, on and off the water, providing direction, motivation and strategy during the race.  The 8 seat, who sits directly in front of the coxswain is the stroke seat.  The stroke is, at the coxswains direction, setting the pace for the boat. A Stroke needs to be confident, strong, level headed and consistent. They can’t let the stress of the race and their emotion get the best of them. 7 seat shadows 8 and must match the pace of 8 for those on the opposite side of the boat, following, yet setting the appropriate pace. Six seat through three seat are considered the engine room. They are the powerhouse at the core of the boat. They follow the 8 and 7 seats and pull hard, though, perhaps, less technically efficient than other positions in the boat.  The bow pair  (two and one) must have excellent technique.  The front of the boat is the narrowest and they must deal with any instability or motion generated in the rest of the boat.  One and two make constant adjustments attempting to make the boat as fluid as possible.
Coaches are also important. Their job is to try to put the best boat they can on the water. This means that they are looking for the right mix of rowers on their team.  The right mix may not be the strongest rower’s but the mix that makes the boat move the quickest through the water. Coaches must recognize any issues on the team and make adjustments. In rowing, coaches determine which team members impact the boat in different ways by “seat racing”.  Seat racing involves racing two boats and then replacing a person on one team with a person from the other team to see how it impacts the performance of the boat.  Coaches seat race the team looking for the most effective dynamics. When it all comes together they call it “swing”. “All were merged into one smoothly working machine; they were, in fact, a poem of motion, a symphony of swinging blades.” Daniel James Brown.
As in rowing, seek the right mix of skills and roles on your software team.  These include:
·    Leadership
·    Business and product understanding
·    Software architectural skills
·    Software developers and testers  
·    System admin or software configuration management
Unlike rowing, however, these skills don’t have to be in a particular seat on the boat.  While position doesn’t matter, highly successful teams will have a balanced mix of all of the necessary skills and clear leadership.
Software leaders act as coach and coxswain. They aren’t necessarily the best technical architect, developer or tester but they push the team forward. They must constantly evaluate the team skillset and the team dynamics to determine if they have the right mix. Load your boat with people with the skills necessary to make your team the most productive and efficient. Software teams missing key talent and skills will go more slowly or completely get off track. If there is a problem on the team then, as with a rowing team, make adjustments.
A strong architect acts as the “stroke” and is key to establishing a good foundation and design for the rest of the team.  A boat must have a good athlete at the "stroke rower position", someone who can maintain the pace the coxswain is looking for, and set the rhythm standard for the other rowers.  This compares to the team architect who takes direction from the team lead and creates an architecture for the team to utilize. Ideally, the software design should be as simple as possible while solving the problem.  Convoluted or poor design software design occurs when teams don’t have the necessary architectural skills or lack an architectural leader. This can result in a system that is difficult to test.  Conversely, too many architects on the team can slow the team due to conflicts. How would the boat move if there were two rowers trying to set the pace or strategy for the boat?

Software Developers and Testers act as the "engine room".  They generate the force to move the project forward at the pace set by the software leaders and architect.  They work with the architect to develop a cohesive design.  They should have solid software development and/or testing skills and be diligent in their approach. They should have a zeal for developing working software and making sure that the implementation will meet the given requirements.  

Software team members are not interchangeable. In rowing, seat racing is a way to determine the impact of one individual on a boat. As in rowing, replacing one software developer or tester with another could have a big impact on the team.  Have you ever heard an executive say, “Just go hire some developers”.  If Joe knows Java and it’s a Java project then does it matter if we replace Sarah with Joe?  Well, it might… if Sarah has been providing software design strategy to the team and has specific domain knowledge about the application. Perhaps Joe isn’t very good at design and replacing Sarah’s in depth experience could take a long time and slow the team.   Consider the dynamics in your team when making changes.
Successful teams keep their eyes on the end goal. They are diligent in their technique and approach and find ways to be more efficient (make the boat go faster). They work together, not against each other. Imagine if one person in a crew team was working against other team members.  It would be an ugly site, indeed!
Developing software is an art. It takes skill and creativity to develop cohesive, supportable, and easily maintainable software. There are software developers and testers that are more talented than others, or software developers and testers that might be less talented but make your boat go faster. Consider this quote from famous boat builder George Yeoman Pocock:
“It’s a great art, is rowing. It’s the finest art there is. It’s a symphony of motion. And when you’re rowing well, why it’s nearing perfection. And when you near perfection, you’re touching the Divine. It touches the you of yous. Which is your soul.”
Software teams don’t get to experience the motion on the water, the pain of the 2k race or the joy of winning an Olympic medal; however, working on a good project can invoke similar feelings if the team finds it’s “swing”. It’s extremely rewarding to be part of a team of talented people, perfecting their craft, creating elegant solutions and working together towards a common goal.

Tuesday, October 14, 2014

Common Mistakes #5 - Focus on Working Software, Not Tracking Bugs

At a recent industry Agile conference, we shocked a whole room full of people by announcing that 10X does not use a bug tracking system during development and testing.  We were immediately barraged with questions:
  • You can’t write perfect software!
  • How do you not keep track of defects?
  • How do the software testers communicate issues found to development?
  • How do you prioritize bug fixes if you don’t have a list?
  • What about production problems?
  • What about tracking severity 3 or 4 defects?
  • How do you measure code quality?
  • How do you track the effectiveness of QA?
  • Don’t you need metrics to report to management?

Our response:  Tracking defects makes you less efficient. Don’t focus on tracking them, focus on fixing them!

How many long painful meetings have you attended where lists of defects are discussed, prioritized, and subsequently never fixed? The overhead required to discuss, document and manage the defect often exceeds the value derived from those efforts and distracts from the work at hand. Just entering defects can sometimes take more time than fixing them.

Often teams keep metrics on the number of test cases run and defects found and fixed.  Management then uses these metrics to determine productivity. This not only creates overhead but can incent bad behavior. In the past, we have seen testers write test cases of low quality or run test cases they knew would fail so that their metrics would look good.   How ridiculous!  Focus on what matters! 

In the end, working software is the goal, not how many bugs were found along the way.

During a project, avoid defects by developing and testing feature functionality within the same team and within the same few sprints. We don’t split the development and test organizations. They work together as one team. When a defect is discovered, the team discusses it and decides whether it should be addressed during the current sprint. If so,  it gets added to the current storyboard.  If the defect is not deemed critical enough to fix immediately, the team may add it to the backlog or simply decide that it will not be fixed.   The point is to avoid the extra effort involved in adding defects to a bug tracking system and to fix them as quickly as possible so that you don’t accumulate a lot of technical debt and spend time managing that debt.

Production issues can easily be worked into the current sprint. If there is no team currently in place actively doing development for that product, the bug can be worked into a backlog or storyboard managed between the supporting development and operations groups. New tests can be added to the test automation suite and can be used to validate that the fix hasn’t broken existing functionality. Granted not all bugs are that easy to find or fix in production and customers may require tracking.  Keep it simple. Pick simple tools to help keep track that don't add too much overhead. Do not allow the list to grow! If your bug lists become large then, perhaps, there is a different issue that needs to be addressed.

Friday, October 3, 2014

Common Mistakes #4 - Forgetting to Have Fun

Sometimes organizations are so focused on schedules, deliverables and budgets that they forget to take time to have fun. Remember the song “Girls Just Want to Have Fun” by Cyndi Lauper?  It’s not just girls, it’s everyone. Taking time out to play can improve team interaction, enhance job satisfaction, and, let’s face it, it’s just more fun.

One definition of “fun” from Merriam-Webster is “what provides amusement or enjoyment." What is fun for one person may not be fun for another.  Different age groups might have fun in different ways.  Try to look for ideas that appeal to different people and make sure that fun activities are optional so that you don’t alienate people who would rather not participate.

Many organizations use the excuse that they don’t have budget to do fun things.  Fun doesn’t have to be expensive. There are plenty of ways to have fun without spending money. We’ve found that brainstorming with our teams is a great way to gather ideas.  At our recent onsite company meeting we did a number of fun activities that weren’t expensive or difficult to do.

  • Game night -  This is easy to do in an office conference room or lunch room.
  • Guess the secret - Have everyone submit something about themselves that people wouldn’t know. Then have everyone to guess which secret belonged to which person.  This activity generated a lot of discussions and jokes over the course of the week and people continue to reference the fun facts.
  • Name the office - we held a contest to name the rooms in our new office space. This sparked a lot of creative names and laughter.

Some other possible activities:

  • Informal happy hour
  • Field trips to interesting local places (museums, Fish Hatchery, etc)
  • Lunchtime movies with pizza
  • Watching sporting events that take place during the day (World Cup, Olympics, etc)
  • Informal group gatherings (birthdays, project milestones, etc)
  • Minute to win it games

Encourage fitness within your teams.  Providing opportunities for people to exercise can be a way to add fun to your work environment.  Exercise decreases stress and anxiety and improves productivity.

Consider some of these activities:

  • Sporting activities (bowling, softball, curling, racquetball, tennis etc)
  • Sponsoring a charity event (walk, run, etc)
  • Fitness challenges
  • Providing work flexibility for people to have time to exercise
  • Walking meetings - get outside and walk and talk on a nice day

Sometimes the most fun can happen spontaneously during informal gatherings in the lunch room or other shared spaces.  Employees can have fun just joking around with each other. Think about ways to bring people together. When people have fun together they start to gel and understand each other. They work together more effectively. In fact, the good times are what they will remember most.  

Thursday, September 4, 2014

Common Mistakes #3 - Forgetting to Think Lean - If It Doesn't Add Value, Don't Do It

As an organization, one of your biggest challenges can be getting work done with the people you have.  Instead of adding additional resources, consider optimizing the time of your current employees through the adoption of lean principles.  

At their core, lean principles are about creating value.  If a process, task, meeting, status report, or any other activity does not add value to the team, end customer or consumer, consider it wasteful and stop doing it.  To help identify additional waste, take time to review your current procedures on their own merit and don't do them just because you’ve always done them a certain way.  Determine the value of the procedure versus the cost of producing such value.  If the cost of an activity is high in time and energy but achieves limited benefits, eliminate the activity.  Often understanding this cost is enough to convince yourself and others to “find a better way”.

You probably already know of tasks in your organization that are costly but must be done.  For example, financial audits, inventory control, or certain aspects of your development  process that may be mandatory for your business.  Consider automating and streamlining these tasks as much as possible to lower costs.

When developing software, resist the urge to develop features that do not add value for your customers.  If you cannot identify a specific user for a feature then do not implement it or defer it until the feature can be proven to add value.  Take time to identify the value that a feature will provide versus the cost of developing it.  When identifying costs, be sure to account for not only the development cost but also the testing, user documentation, training, and support that will result from the feature for the life of the product.  Automating testing of features will also help offset the costs of features that make it into the system.

These suggestions will assist you in eliminating waste in your organization.  Speed can be considered as the absence of waste, so eliminate the waste and you will respond to the important issues faster and achieve a higher degree of efficiency in your business.