A Better Work Day

posted Jul 12, 2016, 2:37 PM by Anjuan Simmons   [ updated Jul 21, 2016, 4:38 PM ]

There have been a number of recent posts that make the case for the mornings as the time of peak productivity. For the average person, that window is between 9 AM and 11 PM. However, what do most people do during those hours? They check email, browse Facebook, or sit in meetings. That is not the best way to use the most creative and productive hours of the day. However, most workplaces structure their day in a way that squanders the efficiency of their human capital.


I propose a way to have a better work day. Since I work in software development and love Agile, I’ve included a morning Scrum in my example. In my experience, Scrums are best held in the morning before team members settle into their day. A Scrum should take no more than 30 minutes. The ones I run average around 7 minutes in duration, but I allocate half an hour for padding. You can replace that scrum time with whatever works for your industry



Notice that the afternoon is reserved for meetings because people have usually spent their productivity doing their morning work. Also, notice that there are only 3 options for meetings: 2:00, 3:00, and 4:00. I believe that meetings are massive wastes of time, and most of them are run poorly. So, limiting the number of meeting slots forces meeting organizers to schedule and manage them wisely. Of course, if your office has three meeting rooms, then you can have 3 meetings at 2:00 (one in each room). But, they all should last no longer than one hour.


I also propose a rule that you cannot schedule a meeting any earlier than the next day. If something is urgent, instead of scheduling a meeting right now to discuss the problem, find a key decision maker and engage one on one. Afterwards, send an email summary of the problem and selected decision to all stakeholders.

Virtual Scrums Using Slack

posted Jul 12, 2016, 2:20 PM by Anjuan Simmons   [ updated Jul 21, 2016, 5:10 PM ]

I believe in Agile software development. I'm an Agilest. However, Agile software development is not doctrine. I believe in agile because it is a framework for making software development better and not a list of rules that everyone must follow to be successful.

The flexibility of Agile development is what makes it so powerful. I recently experienced this when I moved my team from in-person daily scrums at 9:00 AM to virtual daily scrums. I decided to do this by using an online collaboration application called Slack. After testing it alone for a few days, I sent this email to the team:

Team,

As I said in this morning's scrum, I would like to beta test virtual Scrums using Slack. Our Slack organization is:

http://########.slack.com

Everyone should have received an invitation to join by now. If you have not, let me know.

I like to keep things flexible but structured. So, here are the guidelines for our beta of virtual Scrums:

1. For the rest of the year, instead of meeting in-person in the Hub at 9:00 AM, we’ll use Slack. All scrum updates must be entered into the #scrum channel on Slack by 9:00 AM every work day.

2. All team members must check the #scrum channel at 9:00 AM every morning to read the latest updates. If you see anything that needs to be corrected or clarified, collaborate with the respective team members and update the #scrum channel if necessary.

3. In exchange for not having in-person meetings , we'll need a greater level of detail in the daily updates. So, instead of typing "bugs", the update should include the bug numbers that have been fixed and the ones that are planned to be fixed today. Similarly, QA should include the tests they have run and the tests they plan to run that day.

4. This is a beta while we're in bug fixing mode and not working on features. Also, as we wind down the year, we'll give you just a little time back to you each day as we get ready for time off during the holidays. However, if virtual Scrums are not robust enough to guide our team once things ramp up in 2015, we'll go back to in-person Scrums.

Slack has apps for iOS, Android, Mac, and Windows. I recommend installing at least one of them on your platform of choice.


It has only been a few days, but the results have been very positive. I've managed the team to a high level of efficiency during our morning Scrums. However, that has led to very concise updates like developers saying they're working on "bugs" and testers saying they're "running test scripts". By using our #scrum channel on Slack, the team is providing specific bug numbers, test scripts, and other information. It took a change of the medium to elicit a change in behavior.

I was able to get this positive result because of the flexibility of Scrum. We may go back to in-person daily scrums, but, for now, our virtual Scrums are delivering real results.

Why Small is the Key to Big Agile Results

posted Jun 9, 2016, 12:39 PM by Anjuan Simmons   [ updated Jul 21, 2016, 6:36 PM ]

It’s tempting to solve software application performance problems by throwing hardware at the problem. Since machines are relatively cheap, horizontally scaling by adding more servers is a common initial remedy. However, this soon runs into diminishing results since large numbers of machines can’t optimize code.

The same principle applies to Agile software development teams. Since the market can provide nearly unlimited sources of programming talent, hiring more developers is a common remedy for solving the perception that not enough work is getting done. However, a large number of developers can’t optimize the work that flows through the Development Team simply through numeric strength.

Contrary to what most people would intuitively think, taking a small approach to software development can increase the amount of work that can be completed by an Agile software development team, especially those that practice Scrum. This requires understanding the concepts of small teams, small releases, and small vertical slices.

Small Teams

I’ve seen Scrum Teams with 20 or more developers, and my first instinct is always to break them up into smaller Scrum Teams. Scrum recommends that the Development Team should be between 3 and 9 people. If a Development Team has less than 3 people, then it may be difficult to have all of the skills needed to complete the potentially shippable product increment by the end of the sprint. If a Development Team has more than 9 people, then coordination costs begin to dramatically rise.

Let’s say you have one Scrum Master, one Product Owner, and five Development Team members. That is a total of seven people on the Scrum Team. The number of communication channels for this seven person team can be calculated using the formula n(n-1)/2 where n is the number of people on the team. Using this formula, we can determine that there are 21 communication channels. However, adding more people to the team dramatically increases the number of communication channels:

Team Members      Communication Channels
828
936
1045
1155
1266
1378
1491
15105
16120
17136
18153
19171
20190

For example, if three people are added to the seven person Scrum team (a 30% increase in team size), you more than double the number of communication channels. If you double the seven person Scrum Team to 14 people, you more than quadruple the number of communication channels.

Small teams are better positioned to efficiently and effectively manage Scrum events like Sprint Planning, the Daily Standups, the Sprint Review, and the Sprint Retrospective. Having a small team size increases the likelihood the team communication is focused and fast decisions can be made.

Since Agile teams thrive in an environment with co-located teams that interact through face-to-face contact and regularly reflect with each other, Development Teams with more than nine people can’t communicate effectively enough to maximize their agility.

Small Releases

It can be tempting to drive a software development team to deliver big releases chock full of awesome features. However, small releases with a small set of features provide benefits to both the team and to customers.

When a team considers which items to pull into the Sprint Backlog from the Product Backlog during Sprint Planning, small features (we call them user stories) are essential. Small user stories are easier for the team to understand because the work is specific and granular. This simplifies the process of determining the effort needed to complete each feature by the Development Team. Small user stories reduce the difficulty of determining the complexity, risk, and size of features by lowering uncertainty. The Product Owner and Development Team can quickly obtain a shared understanding of the work and produce accurate estimates. Furthermore, smaller user stories allow Development Teams to feel an almost daily sense of progress as they finish features throughout the execution of the sprint.

When a small set of features are delivered to customers, they are better able to understand the delivered software and provide feedback. Give a user ten complicated features and they’ll delay giving you feedback for as long as possible. However, give a user three simple features, and you’ll get feedback before you return from your coffee break. The human mind can only process so much information at once, and we delay analyzing large data sets when we can get away with it. You can confirm this by simply checking the number of unread emails in your inbox.

Small Vertical Slices

Developers often think of applications in terms of horizontal layers, and they often build software layer by layer. For example, developers will often build the entire back end database for a release, then the application logic, and then the user interface. It’s not uncommon for Development Teams that take this approach to finish a sprint with one layer “Done”. However, this is not a working product increment. How can a back end database be discussed during a Sprint Review? How can a user interface, no matter how elegant, be shown in a demo if it doesn’t work? Furthermore, delivering these layers separately from each other hinders the ability for upper layers to teach you about the lower layers. For example, if the back end database is fully developed before the user interface is started, then problems that can only be detected by the UI can result in the need to rebuild the database.

A better approach is to think of applications in terms of features composed of vertical slices that each have a data, logic, and presentation layer. Therefore, working on Feature X means creating the database tables, business logic, and user interface for Feature X. This greatly increases the chance that Feature X will be working by the time of the Sprint Review and can be verified by the Product Owner. By building out an application vertical slice by vertical slice, the Development Team can deliver features faster and learn things from early vertical slices that can be applied to future vertical slices.

The next time you spin up an Agile software development team or try to improve an existing one, consider taking a small approach. Seek to create a small team that delivers small features in small vertical slices. You may be surprised by the size of the results.

Four Retrospective Techniques

posted Apr 21, 2016, 1:33 PM by Anjuan Simmons   [ updated Jul 21, 2016, 4:39 PM ]

Many Agile teams are unaware that there are different techniques for conducting Sprint Retrospectives. I've written up the different techniques available to Agile teams many times. This list is not exhaustive, but here is an overview of four Retro techniques:

4Ls (Liked, Learned, Lacked, Longed For)

This technique is fairly popular because it's easy easy to understand and focuses on facts. Each member of the team shares four topics at the end of the sprint: things they liked, things they learned, things they lacked, and things they longed for. The Longed For topic also allows Retros to be more future-looking. This technique also supports the parsing of positive things (Liked and Learned) and not-so-positive things (Lacked and Longed For) without the value judgement underlying the Problems topic in our current technique. 

Start, Stop, Continue

This technique is popular because it's easy to understand. This technique focuses on actions. I like this technique because I think it's the easiest to use for deriving action plans. It also, through the Start topic, helps the Retro be more future-oriented. However, depending on the way people share their items, it can be difficult to determine the emotional state of the team using this technique.

Mad, Sad, Glad

This technique is very popular because it does something a lot of Agile teams like doing during Retros: vent. This technique focuses on emotions. I've used a variant of this technique called Good, Bad, Ugly. While this technique is widely used, I think it's the hardest to use for creating action plans. It is also difficult to be future-oriented using this technique.

Successes, Problems, Opportunities

This technique if fairly well used, and it focuses on events. It is a good technique to use for reviewing the institutional memory of the team. This technique is focused on what happened during the last sprint, but the Opportunities topic can be used to think about the future and possibly create Action Plans.


Some Agile teams do mash ups of these Retro techniques. For example, if the team wants to understand the emotional state of each team member while also facilitating the creation of Action Plans, a team could adopt a Glad, Mad, Start, Stop technique. Regardless of the technique chosen, it is vital that the Development Team is involved in the selection process.

Formulating a Code of Conduct and Team Constitution for Your Agile Team

posted Feb 9, 2016, 10:17 AM by Anjuan Simmons   [ updated Jul 21, 2016, 4:40 PM ]

I believe that company and team culture are vital aspects of any Agile team. Culture plays out in every day interactions from how we treat each other to how we conduct meetings. I have found it useful to help my teams come up with a Code of Conduct and Team Constitution to document the culture of the team.

Team Code of Conduct

This is an agreement for how the team will interact with each other. It is similar to a Bill of Rights that list the things the freedoms to which each member has a right.  Here are some examples from teams I've worked with in the past: 
  • When we meet as a group, each individual will give total attention, without distraction, to the person speaking. 
  • No discussion will be interrupted except by the least intrusive means possible.
  • All ideas will be treated with respect.
  • Rejection of an idea will not be seen as rejection of the source.
  • The best idea will be supported regardless of the source.
  • Majority support for an idea will be sufficient for its ratification regardless of any individual distaste for the idea.
  • No actions will be taken to deliberately cause harm.
  • Seeking to understand will be preferred to seeking to be understood.
Team Constitution

This is how the team handles routine activities. I can't share specific examples, but here are some of the questions that Team Constitutions should answer:
  • How do I decline to take part in something (lunch and learn, happy hour, etc.)?
  • How do we start team activities (meetings, Retrospectives, Reviews, etc.)? 
  • How do we ask for help from each other?
  • What do we do if someone does something in violation of the Team Code of Conduct or Team Constitution?
  • How do I check someone's intention if I think they are doing something that I think will not result in a positive outcome?
  • How do we make decisions as a team? Do we take votes? How are votes counted? What constitutes a majority?
  • How do we meet the needs of those who lose votes and get them to support the decision of the team?

Tailoring Agile Practices

posted Jan 4, 2016, 1:50 PM by Anjuan Simmons   [ updated Jul 21, 2016, 4:40 PM ]

Here is a question that was posted in one of the Agile Linkedin groups I follow:

I would like to know how to you select the appropriate Agile method(s), I mean what are the processes of selecting the suitable Agile method(s) for different situations, and what hat are the factors that you consider when selecting Agile method(s) for different projects, different organisations and different team and/ or different situations?

Here is my response:

I would be wary of any "process" for tailoring the various Agile practices. That would be similar to a process for having a successful marriage. The realities on the ground are so varied and diverse that any process quickly becomes wrong.

You need someone experienced in understanding what's going on in your organization and applying the Agile practices that best meet your needs. This requires an organic and iterative approach that will take time to demonstrate results. Anyone who says they can provide a "silver bullet" that will immediately please upper management should be ignored. If upper management wants immediate results from an Agile transformation, then you have already lost.

I usually start with a presentation of the 12 Principles behind the Agile values  to both the people doing the work and any relevant stakeholders. If they don't value the majority of the Principles, then I know that Agile will fail at that company.

Moving from Individuals and Time to Points and Velocity

posted Aug 26, 2015, 12:45 PM by Anjuan Simmons   [ updated Jul 21, 2016, 4:40 PM ]

I've been in meetings with many CIOs where the CEO demands to know when features will be done. CIOs inevitably resort to framing their answer in terms of individuals and time. This is fine in a waterfall environment, but this framing is often done on Scrum projects. I usually (in private) coach the CIO in a discussion or email that goes like this:

I wanted to share with you my thoughts about communicating to upper management when things will be done. During the last meeting I attended that included you and the CEO, this exchange happened several times:

CEO: When will this feature be done?

YOU: It will take one developer # weeks.

I think that communicating timelines to the CEO in terms of individuals and time estimates is, while common, sub-optimal. This is based on two theories:
  1. Finishing a feature takes more than the skills of a developer. Getting a feature to Done requires QA and often design resources. That's why Scrum uses story points to size features according to the Definition of Done which includes all of the work needed to get a feature to Done.
  2. Humans are bad at making time estimates even when using concepts like "ideal days". Also, upper managers tend to "do the math" with time estimates by trying to do calculations based on number of developers and how many days of work they get get out of a sprint. That's why Scrum uses velocity (a dimensionless value) as a measure of what the team can get done in a sprint.
So, based on these two theories, exchanges with the CEO would go like this:

CEO: When will this feature be done?

YOU: That feature is, relative to similar features we've done in the past, # points. The team has a velocity of X, so, if the team only worked on that one feature, it would take Y sprint(s).

By doing it this way, you give our CEO an estimate based on everything needed to truly finish a feature. Of course, it's even better if the size communicated to her comes from the team that will do the work. However, I know the investment of time required for team estimating may not be possible before giving an estimate to our CEO.

This exchange has to be done in the context of the team assigned to any given project. It is natural for velocities to vary widely between Scrum teams.

Of course, there is no way of communicating estimated times to complete that cannot be gamed or questioned by a CEO. However, I think that using points and velocity gives the CEO what she wants with a reasonable degree of accuracy.

Perfect Software vs Crappy Software vs Acceptably Shippable Software

posted Jul 15, 2015, 11:21 AM by Anjuan Simmons   [ updated Jul 21, 2016, 4:41 PM ]

As a Scrum Master, I often write emails to my Development Team to bring them back to First Principles. This is an email I wrote when we were struggling with a feature that we knew could not ship with the polish we all wanted it to have. The team had to meet a hard deadline so, as is the case when time is a constraint, scope had to be reduced.


Team,

I've been thinking about how to balance the implementation of this feature between Perfect Software (which never ships) and Crappy Software (which ships all too easily). How do we get to Acceptably Shippable Software?

I hope we can all keep in mind that this release won't be the last time we touch this feature. If we can find an acceptable implementation for the majority of our users, we can iteratively improve that implementation one to two sprints after the release. This will allow us to firm up our thoughts about the feature and also hear from our customers. In addition, shipping by our deadline will provide some internal relief that I think we can use. As I've said, "Shipping heals all wounds". The assumption, of course, is that you don't ship pain.

I trust that the team can find the right balance as we work together.

Making Room for QA in Scrum Sprints

posted Jun 4, 2015, 7:50 AM by Anjuan Simmons   [ updated Jul 21, 2016, 4:41 PM ]

It is not uncommon for members of Scrum Development Teams who perform QA activities to complain about work being given to them at the end of a sprint leaving little time to complete tests of features. Here are some solutions that I have shared with one of my Scrum Development Teams to address this problem:

I've been going through the Retrospective feedback shared over the last few sprint and thinking of ways that I can address some of the problems that have been shared. One problem was the experience of having little time to QA features that were developed and code reviewed toward the end of the sprint. A correlated problem was the feeling that QA was relatively idle early in the sprint and then went into overdrive at the end of the sprint. These problems may have reduced in severity since we always have features in QA that move on to the next sprint. So, QA is busy finishing features that did not make it to Done in the previous sprint. However, I think that this is masking the problems rather than solving them. So, I wanted to present some solutions that I've used in the past that I hope will help once we have fewer cards moving across sprints.

The first solution is to turn the problem on its head by creating the tests for features before they are implemented. After we analyze and size features in Sprint Planning, instead of development immediately working on the feature, the QA team will create the tests (manual or automated) based on their understanding of the feature. This is a great way to make sure that any QA related questions about a feature are answered by the Product Owner. Once the tests are created, the features are implemented in code. Of course, there will still need to be an actual test pass once the feature is complete.

The second solution is an iteration of the first one. After features are analyzed and ordered during the Backlog Grooming session, the QA team can create tests for features at the top of the backlog. This will allow QA to "get ahead" of work that is likely to be worked on in a current sprint.

It's my understanding that the team has experience doing testing before implementation so I know that these are not new ideas. However, I hope that the team can use them to resolve some of the issues raised in past Sprint Retrospectives. 

Creating Meeting Free Zones at Work

posted May 28, 2015, 7:57 AM by Anjuan Simmons   [ updated Jul 21, 2016, 4:41 PM ]

There have been a number of recent posts that make the case for the mornings as the time of peak productivity. For the average person, that window is between 9 AM and 11 PM. However, what do most people do during those hours? They check email, browse Facebook, or sit in meetings. That is not the best way to use the most creative and productive hours of the day. However, most workplaces structure their day in a way that squanders the efficiency of their human capital.


I propose a better work day and an example is below. Since I work in software development and love Agile, I’ve included a morning Scrum in my example. In my experience, Scrums are best held in the morning before team members settle into their day. A Scrum should take no more than 30 minutes. The ones I run average around 7 minutes in duration, but I allocate half an hour for padding. You can replace that scrum time with whatever works for your industry.

MeetingBox


Notice that the afternoon is reserved for meetings because people have usually spent their productivity doing their morning work. Also, notice that there are only 2 options for meetings: 3:00 PM and 4:00 PM. I call this the "Meeting Box" because that's the time box within which all meetings must be scheduled. I believe that meetings are massive wastes of time, and most of them are run poorly. So, limiting the number of meeting slots forces meeting organizers to schedule and manage them wisely. Of course, if your office has three meeting rooms, then you can have 3 meetings at 2:00 (one in each room). Or, if your organization uses virtual meetings, you can have nearly an unlimited number of meetings inside the Meeting Box as long as the attendees vary. However, they all should last no longer than one hour.


I also propose a rule that you cannot schedule a meeting any earlier than the next day. If something is urgent, instead of scheduling a meeting right now to discuss the problem, find a key decision maker and engage one on one. Afterwards, send an email summary of the problem and selected decision to all stakeholders.


I once worked at company that had a "Meeting Free Day" where no meetings could be scheduled. Our Meeting Free Day was every Friday. Having the Meeting Box and Meeting Free Day are great ways to unleash productivity by creating Meeting Free Zones at work.

1-10 of 21