Put iOS 9 Into Your Product Backlog Now

Awesome. You have a mobile app built on iOS 8.3. The problem is, when Apple releases iOS 9, your app might break and you will lose customers.

I am going to share some techniques with you on how to manage this risk and potentially avoid all problems, while keeping the rest of your business well aware of the activities of your engineering team. While this is not the only way, this is an approach I used in the past which has resulted in a positive outcome.

Beta-time!

Apple provides beta releases of iOS. Because they make it available, you have the ability to explore new features, but also, see what still works and what breaks in your existing app. This is the key to the framework I am going to share.

The framework for managing this kind of work is as follows:

• Test Through Stories
• Fix stuff
• Repeat

Test Through Stories

Since the backlog is the source of work the team works from, you can create a user story in your backlog to test your app. Here is a sample user story:
As a product owner, I want to know what issues my app has with iOS 9, Beta 1, so that I can prioritize fixes.

Note how the story is specific. iOS 9, Beta 1. There is no ambiguity what needs to be tested. The purpose is clear. You want to know what the issues are. The team knows this story isn't to make sure the app works with iOS9, Beta1, but rather to find what doesn't work.

The acceptance criteria might look like:
The application is tested on an iPhone 6 running iOS 9, Beta 1
All defects are entered into our bug tracking system

You may want to have different stories for different target hardware devices such as iPhone 5S, iPhone 6, iPhone 6 Plus, iPad Air 2, etc.

When the team completes the story, during the Sprint Demo or Sprint Review, the team can demonstrate the app running in the new iOS build, summarize the defects found, and highlight some of the of the key defects that were discovered.

Future Stories

Although Apple hasn't released additional beta versions of iOS 9, it is safe to assume more will come out and you can put those into your backlog now. Doing so will provide more visibility to the team and business of all the work the team needs to do, as well as any impact to schedules or other features. I will touch on this topic more in the Repeat section towards the end of this post.

Additional Considerations

Some behavior might be perceived as a defect, but could be a flaw of the beta release of iOS. The team will have to be very careful in evaluating each defect and making a determination or best guess as to what the cause of the defect might be. To play it safe, document everything so that you can retest it in a future release of iOS.

See What You Did There

In brilliant fashion, you leveraged the process and tools at your disposal to protect the product and incorporate technology updates into the backlog and roadmap. The business now has greater visibility and awareness of changes in the technical landscape. The team also appreciates your forethought to anticipate this kind of inevitable change. Well done.

Fix Stuff

Now that you have a list of things that are broken, you can prioritize those items in the product backlog, just like you do with everything else. Some defects you will be able to fix, and some you won't (perhaps due to schedule pressure or other constraints). Hopefully, you will be able to get all the necessary fixes in place before iOS 9 goes live.

As mentioned before, some defects might be related to unfinished features of iOS 9 and some might be proper compatibility issues such as consuming an obsolete API. Refer to the iOS documentation to help making this assessment and ensuring the proper fix is put in place.

Repeat

You will also have to decide if you want to test every beta version that is released. This will be a function of budget. When you have a lot of automation, or if testing is cheap, then you can play it safe and test every version that is released. If testing is very expensive and time consuming, you might not have the luxury to test each version, and will have to decide what versions will be skipped.

Looking at iOS 8, there were 5 beta releases with the first on June 2, 2014, a gold master release on September 9, 2014, and public release on September 17, 2014. This means you had 14 weeks to test, fix, and release you app while maintaining new feature development. That is 7 two-week sprints. Depending on the release schedule and frequency of iOS, you could have been testing 6 out of the 7 sprints.

On a past project, we made the deliberate choice to skip some beta releases due to other feature priorities. We skipped the first, third, and fourth release of iOS 8, but tested with the others.

Retrospect and Celebrate

After that last minute crunch to fix those final pesky bugs before the iOS 9 GA and you get submit your app to the App Store, take a breather. The team worked hard and discovered many new things. There might have been some realizations about the application architecture that could have made the compatibility with iOS 9 a little easier. Work these observations and architectural improvements into the backlog to better position your product for iOS 10!

Also, celebrate with the team. Buy them food, silly shirts and nerdy gadgets. This might have been a major or minor release of your product. Show your appreciation and gratitude to the team who made your product success possible.

Best of luck and happy coding.

Scrum Potato: Orchestrating a Daily Stand-up

While it is ideal to have team members co-located in a single office, floor, or room. If you happen to have team members in different locations throughout the country or world, you might find a challenge when running a daily stand-up. Sometimes the meeting becomes a bit silly with people talking over each other, dead air where people aren't sure who should go next, or someone orchestrates the sequence of the speakers.

Being a ScrumMaster, one way to help facilitate this meeting is to play ScrumPotato. Based on the game Hot Potato, the method is simple:

1. ScrumMaster starts it off by asking someone to start.
2. That person shares the necessary information for the Daily Stand-Up. When complete, that person chooses who to pass to next.
3. Repeat until all team members have taken a turn.

Some benefits to this include:

1. Its different. Sometimes, it is good to change things up to keep things interesting. Of course, if this is too distracting and the meeting is actually worse, please revisit what you're doing.
2. Encourages better listening. Since the order is unknown, through observation, team members tend to listen better using this model. Being in different locations and not always having visual contact with everyone, listening is a huge factor.
3. Encourages better preparation. Just like in the game version of Hot Potato, ScrumPotato tends to have people more prepared and keeps them on point.

Please give this a shot and share any feedback on how this benefits your team or how you modified this to better fit your needs.

If your team is all standing in one room, it might be fun to actually have a small object or chainsaw to pass around. This helps with the eye contact.

Enjoy.

Book Review: Managing Software Debt

Recommendation: Must Have

I have recently read the book "Managing Software Debt" by Chris Sterling and must say I am quite impressed.  The author does a fantastic job explaining the subject and provides a lot of guidance on how to deal with the issue.  If you want to talk about ROI, this book is so packed with ideas and inspiration, it should cost thousands.  The author maintains an open mind throughout the book, and by reading this, you do too.

The author addresses software debt at many levels, more than I knew existed.  This book is part of the Agile Software Development Series, but I think this is a core book everyone involved in a software project should read (chickens and pigs).  I am surprised to see so few books on the topic, but this book is so well put together, I don't know if other books are needed.

Buy it, read it, follow it.

Cross Functional Teams vs Cross Functional Team Members

There is no doubt that having a cross functional team will increase your chances for success.  When the team is able to resolve their own issues and complete the work needed independent of external dependencies, the fault of delays fall onto that team.  Being cross functional empowers the team to better control their fate.  But that is where most organizations fall short.  Not only do you want to have cross functional teams, but you want to have cross functional team members.  Let me explain.

What does a Cross Functional Team look like?

A cross functional team has the necessary skills to deliver product features end-to-end.  In the example of a web application, it will involve people who have database, middle tier, and presentation tier skills.  If the application is graphic intensive, a graphic designer might be part of the team.  If the team as a whole, can cover the skills needed to deliver end-to-end features for 90% of the project, then the team is cross functional.

What about Subject Matter Experts (SMEs)?

The SME is someone who is an expert at a particular field or subject, where that skill is needed for the project, but does not quite need continuous involvement with the team on a daily basis.  Typically, these skills are around architecture, legal, marketing, and operations.  Depending on the app, you may want to staff your team to have one of these SMEs as part of the team.  Something to help you decide this is this question, “How often will the team go to this SME to complete a feature end-to-end?”  If you find yourself needing to go to this SME regularly and frequently, then consider making them part of the delivery team.

Okay, but what is the big deal about cross functional team members?

We have described cross functional teams, but cross functional team members is a different concept.  A cross functional team may be composed of a DBA, two developers, two testers, and a graphic designer.  For most end-to-end situations, the team would be able to implement potentially shippable features.  In practice, not all features will require such an even distribution of skills.  That is to say not all features will be 17% database work, 33% development, 33% testing, and 17% ui.

A cross functional team composed of cross functional team members may consist of 5 engineers.  Each engineer has skills in databases, development, testing, and ui design.  The strength of each discipline will vary among team members, but as a collective whole, they have the skills to get things done.  More importantly, everyone can contribute to each discipline.

This helps mitigate risk when in one iteration, you have unbalanced work.  At the beginning of a project, there may be more database work needed than ui.  In the middle of a project, you might need significant database work because a design flaw was discovered and some refactoring needs to be done.  If you only have a cross functional team, then your DBA will be overloaded.  If you have cross functional team members, those members can help contribute to the database workload.  This approach also supports Kanban development methodology.

Divide, Conquer, Swarm

In action, this is how cross functional team members would operate.

Divide.  The team would strategically divide up the work that needs to be done for a feature such that it would play off their strengths.  Having people do areas of work where they are strong will produce faster results.  You also want to make sure you create opportunity for cross training (paired development).  Pairing with the strong-skilled team members will help elevate the skill on the team.

Conquer.  With the work divided, the team would attack the pieces with full force.  But it is not just all about getting your piece of work done.  Along the way, talk a lot with others and integrate as much as possible.  Get those data access calls hitting the database.  Wire up the UI with the presentation and business logic.  At a minimum set up the interfaces so the feature is making calls all the way through the call stack, even if the logic in the middle isn’t there yet.

Swarm.  As one group (pair) completes their work, they will move on to help their other team members get their work done.  If the database work is done, help out the data access group.  Maybe they need help with unit tests, or implementation.  Perhaps coordinating with the tester on the use cases that need to be supported.  The goal is to swarm the other team members with overwhelming support and assistance.  This will also foster a strong team motto of “We’re all in this together”.  You will have bottle necks, but this swarm technique will help eliminate the bottleneck.  This is only possible if you encourage cross functional team members on an already existing cross functional team.

If you staff your teams as 3 developers and 3 testers, where the testers are not allowed to write application code, you’re setting yourself up to have bottlenecks.  If developers can’t help write tests…bottleneck.  If your DBA goes on vacation…BOTTLENECK.

Requirements Are Dangerous

Here are some problems with requirements:

• Requirements are incomplete
• Requirements are wrong
• Requirements include features that don't make sense or will likely not be used

The problem with giving the requirements to engineers are:

• Engineers think the requirements are complete
• Engineers think the requirements are correct
• Engineers think this feature is worth implementing
• Engineers take the requirements too literally

This gets very expensive very fast.  Some recommendations to fix this problem:

• Talk to the person who provided the requirements.
• Review the requirements in person and in real time (not via email or by passing a doc back and forth)
• Question the value of the feature
• Demo the product as it is being developed to make sure you are on the right path.

For those of you who will take this article literally and argue the definition of "requirements", you probably take the requirements too literally too and have been falling into the same problem for years.

Scrum: Accomplished vs. Did, Hidden Impediments?

Think about what you did yesterday and what you are going to do today. You can probably make a list of things. Take a shower, eat lunch, go to some meetings, work on this project, refactor some code, etc.

accomplish 1: to bring about (a result) by effort

Now think about what you accomplished yesterday, or what you are going to accomplish today. You will likely have a different list. Finished reading a book or chapter, got requirements from our customer, verified a bug, etc.

do 3a: perform , execute

In your daily stand-up meetings, be aware of people talking about what they did or are going to do instead of talking about what they accomplished. Regardless of your position on the team (Product Owner, ScrumMaster, Delivery Team member), everyone should hold everyone accountable for talking about accomplishments.

If you have a lot of things to do, where those things don't contribute to your sprint backlog, those things might really be impediments.

Today, I am going to work on the code for the new login system and go to a sales meeting.

Whoa! I hope the ScrumMaster catches this. Is this sales meeting a critical part of the product? Will it interfere with the team's ability to deliver? Is it a 10 minute chat or a 3 hour presentation on something not related to the project? How frequent are these meetings? Was this planned? Perhaps this is a meeting where the employee's manager can excuse the worker from, so the worker can focus on the sprint.

Let's re-do that part of the stand-up in a few different ways.

Today, I am going to start coding the new login system. I have a sales meeting as a blocker. It is going to take half the day.

Today, I am going to start coding the new login system. I have a sales meeting to listen to some feedback from our users.

Hopefully, this illustrates how a different mindset can improve the value of the daily stand-up.

Is Barack Obama the "Scrum President"?

The first moment I thought President Elect Barack Obama might be the first "Scrum President" was while I was watching Obama's Inner Circle Shares Inside Story on 60 Minutes.  David Plouffe, Obama's campaign manager, mentioned how his team only planned for days instead of years.  They were "more agile" and "not afraid to take risks". Now, just because someone says "agile" doesn't mean they follow scrum, but I haven't heard many politicians talk like this group does.

There are a few quotes from another story, Obama On Economic Crisis, Transition, that have elements of "inspect and adapt"

[It] is not always getting it right, but projecting a sense of confidence, and a willingness to try things. And experiment in order to get people working again.

If something doesn’t work that they’re gonna try something else until they find something that does.’

If the idea is right for the times then we’re gonna apply it. And things that don’t work we’re gonna get rid of.

Regarding transparency, Obama said this:

I think that we have to restore a sense of trust, transparency, openness in our financial system.

Scrum is also very big on the concept of "team".  During the week of Thanksgiving (which I don't have a direct reference to, but heard on KNX 1070 radio), Obama said in that America will succeed or fail as one people.

I know I am drawing conclusions on some very loose quotes, and I doubt anyone in Obama's campaign ever said, "Hey, let's run a scrum campaign," but I am seeing enough of an agile spirit, which is the most important thing. 

Scrum and Agile have worked very well for me in software engineering, and I hope it works out well for politics and government too.

Setting Expectations, Getting Results

When people fail to meet expectations, it is often because they didn't know what expectations to meet.  Being a ScrumMaster, team lead, and manager, the most effective way I clear this up is to explicitly tell teams what I expect.  This phrase, although quite obvious and trivial, helps me achieve that goal:

"I expect you to ..."

Yes, it is that simple.  By clearly letting your team (or boss, spouse, friends, etc.) know what you are expecting, they are better equipped with the right information to meet your expectations.  Here is a specific example:

Self-Organizing and Self-Managing Teams
When teaching scrum to a team, I tell them that "Scrum teams are self-organizing and self-managing".  Now that the team has been told, don't expect them to start being self-organizing and self-managing.  Aside from the culture and personality changes that need to occur to make this happen, it is much more effective to additional tell the teams, or individuals on the team, what is expected of them.  I follow-up with this by telling teams and individuals, "I expect you to be self-organizing and self-managing."  This may seem repetitive, but it is very effective.

Here are a few more examples of expectations:

• I expect you to get to meetings on time, not 30 seconds late.
• I expect you to meet  your commitments.
• I expect you to help others with their tasks as though the tasks were yours.
• I expect you to be pro-active, don't wait to be told what to do all the time.

Soft Skills: Anything Else vs. What Else

As a Scrum master, I make a conscious effort to allow the team to be creative and voice their ideas, however, sometime I need to control the pace in time-boxed activities. 

A common activity is asking the team to list items which I write on a whiteboard.  Sometimes teams can be a little distracted, tired, bored, or unsure of what should be on the list.  Sometimes teams are very engaged, passionate, and focussed.  In either case, there are two questions I ask, which I learned from Chris Sterling, which helps me control the pace.

"Anything else?"
I ask this question when we need to move on to another part of  the activity or conversation.  This is most commonly used, but is easy to say "no".  Here is an example exchange:

I am going to the market to get milk.  Do we need anything else?

No, that is it.  thanks.

"What else?"
I ask this question when I think there are more items to put in the list. It is easy to say "no" to "anything else", but when asking "what else", there is more of a compelling reason to give an answer. 

I am going to the market to get milk.  What else do we need?

Hmmm...we need eggs too.

With either approach, if there are or are not any items left for the list, the team has a way out, but one way is easier than the other.

Make it Visible, Make it Big: Sprint Burndown

An important tenant of Scrum is transparency.  Keeping the teams metrics and state of the project visible to others not only enables others to make decision based on this information, but it also has a great psycological effect on the Team.

Where is your team's sprint burndown chart?
A good place to put the sprint burndown chart is in an are where it gets a lot of visibility, but also where important people see it.  The burndown chart can be placed in a Starbucks, but the Starbucks clientèle is not interested in this.  I have placed the burndown chart on the Director of Engineering's office door, or on the door of the Product Owner.  Another effective place to put the chart is in a room or hallway where the peers of the delivery team can see it.  Of course, you want the delivery team to see the chart all the time too.

Make it BIG
People tend to respond to things larger in scale, than small things.  For example, the worlds largest thermometer gets a lot of attention just because it is big.  Nothing special about saying it is 86 degrees, but if you say it in a big way, now you have some attention.

Printing the chart on 8.5" x 11" paper isn't going to cut it.  Draw a chart on a large easel pad (24" x 37") or if you have a HP Designjet T610 with a 44" spool of paper, now that will work.  Add some colors and make the chart easy to read.

Scrum Tools: Points in eScrum and TFS in Visual Studio

I have been using the eScrum project template in Microsoft Visual Studio TFS edition for a few sprints now.  Along the way, the team noticed some issues with the template.  In TFS, by navigating to Team > Process Editor > Work Item Types > Open WIT from Server, I opened the eScrum Product Backlog Item template and made some changes.

Points
The Product Backlog Item template is missing a "points" field to indicate the relative size of a PBI.  There is a Baseline Work field, but that is used to represent the number of hours for the PBI in reports. I decided to add a Points field where a dropdown shows Fibonacci based numbers (0, 1, 2, 3, 5, 8, 13, 20, 40, 100, 250, 500, ?, infinity).  Since there are values such as "?" and "infinity, the field type must be 'String'.  I could have used the Baseline Work field, but that allows people to enter values that could complicate things, such as entering 21 instead of 20.  To avoid the debate, or having to correct this, I added an ALLOWEDVALUES rule to control this.

Query
Now I can create a query to allow me to see what items does the team need to estimate.  By using the team's velocity, this query can include items that are larger than half a sprint, which indicates the team needs to work with the Product Owner to break this down into smaller PBIs.

Certified Scrum Product Owner

In July of 2008, I continued my Scrum education by taking a two-day certification course in San Jose. It was taught by two fantastic trainers: Chris Sterling and Bryan Stallings. I highly recommend this course for any product owner, project manager, program manager, product manager, ScrumMaster, etc., if you are using Scrum or not.

Certified ScrumMaster

In June of 2008, I went to UCLA for a two-day training course to get a ScrumMaster certification. The class was taught by Chris Sterling from SolutionsIQ. I went back to work and started applying what I learned immediately.

The challenge was, I was trained to use Scrum, but others weren't. It was as though only one player knew the rules of the game. So how can I fix this...workshops. By holding a few workshops (or crash course), I was able to get the team up to speed...kind of. I couldn't fit all two days of exercises and material into a four-hour meeting.

After one sprint (two weeks), the team had felt what it is like to sprint. It sure was fast and felt short.

So now the team knows (or was at least informed) of the rules, guidelines, and goals of Scrum, the next challenge is to get them to play as a team. They are in the forming stage of the Tuckman model, and over time, will hopefully get to the performing stage.

By continuous inspection and adaptation, I am looking forward to watching the team evolve and improve over the next few sprints.