Nick Kramer

Nick Kramer


Too Many Meetings: Recognize the Signs

We have received a lot of feedback on our post: Scrum Events – The too many meetings problem. Many people are reaching out to us and provided feedback on the frustration stemming from meetings.  

Meetings in the United States are a big problem.  Nearly 37 billion dollars is wasted annually on unnecessary meetings, and in the Agile community, Scrum meetings are getting the blame.  Our stance is that Scrum is not the issue but rather how companies are their conducting meetings.

Below is a list of the 9 top meeting “smells” to recognize and avoid in meetings:

  • Lack of clearly documented Agenda.
    • If a meeting invite doesn’t have an Agenda, I automatically question the importance of the meeting.  Why should I attend a meeting that the organizer doesn’t think is important enough to generate a clearly defined purpose?

My rule: No Agenda NO Meeting.

  • Lack of definition or goal.  What type of meeting will this be?
    • Status:  Share Information, Provide Status, Give Update.  Participants generally will restrict their participation to questions or clarification about the subject at hand.
    • Advance Thinking: Define and\or analyze a problem, planning session, evaluate options.  Participants are asked to advance the knowledge on a meeting topic.  Decision is not necessarily required.
    • Make Decisions:  Address issues, determine solutions, and bring to closure.  Decision required
    • Obtain Input:  Sponsor is looking for group input.  Decision is not required
    • Retrospective: Strengthen Relationships, Improve Process. Determine what is working? What is not working? What improvements can be implemented?
    • Team Building: Strengthen Relationships, build Mutual Understanding, build community.
    • Skill Development: Training, Increase subject matter knowledge.
  • Lack of defined roles.
    • How do you expect meeting attendees to participate in a meeting?  Are they a subject matter expert (SME), note taker, active participant, observer, or other?  Give those who will be attending the meeting an opportunity to prepare for the meeting based on the Agenda and the Role that they are expected to perform.
  • Scheduling too much time.
    • When a 30 minute conversation blocks off an hour of your day. Did the participants get off topic? Was proper preparation completed in advance before the meeting was scheduled?
  • Meetings that continually go over their time limit.
    • Did you invite the right people? Was proper preparation done? Does the meeting organizer have the necessary facilitation skills?
  • Scheduling meeting to ‘discuss’ when a quick conversation is enough.
    • “Discuss” is never a valid meeting topic.  If you just want to discuss something how about we go to coffee or sit in the break room and have quick chat.
  • Meetings with more than 8 people.
    • Meetings with too many participants can be difficult to manage.  If you are scheduling a meeting with more than 8 people check to make sure the right 8 people are invited.  Ask yourself if the proper pre-meeting preparation has been completed to make the meeting valuable for everyone.
  • Meetings that could be covered in an email or quick conversation.
    • Why waste time with a meeting that could be simply done in an email? If you are not sure, start with an email. Better yet, a quick face to face conversation.
  • Meetings to review previous meeting (rehash)
    • We have all been to meetings that rehash a previous meeting.  Why? Was the first meeting not enough? Did we not send out notes for the meeting? Did new information develop?

Always ask why

Every company has issues with too many meetings.  If you would like to develop skills to help your staff have more productive meetings, check out our Facilitation course.


Custom Software: The Lean Approach

Recently One80 was asked to provide an estimate to a small startup company.  They were looking to build custom software to enhance their existing platform.  The company had a nice set of high-level features that they wished to build, had spent some time interviewing potential users, and even had commitments from several to beta test.

With all the due diligence completed, the client was ready to hire someone to build the new platform.  They had taken the “build it and they will come” approach.

We came in and reviewed their feature set.  We asked a lot of questions about the new custom software, about the problem they were attempting to solve, and the users that they planned to target.  It quickly became clear to us that building the entire platform may not be the best path.  

One80 reviewed the Lean Start-up approach with the client.  We quickly transitioned to the idea of testing the product idea and generating data to help validate the product.  We settled on the Wizard of Oz approach.

For those who are not familiar with the Wizard of Oz approach to custom software development, let me explain:  Just like the iconic movie, what a user sees is not necessarily the whole picture. 

agile software development

The Wizard of Oz approach validates learning by building a functioning user interface. The user interface is nice and it works, but behind the scenes the process of completing the transaction is done manually.  

The business completes the fulfillment of the application manually while tracking data, learning about custom behavior, establishing process, and reviewing potential options.

By completing Lean Start-up testing, the business can validate if the user will actually use the system the way the stated in the interviews and if the new platform will actually solve the users problem.  

Is this cheating? NO! It is Learning.

Why spend cash to build a platform that you are not 100% sure will actually solve the problem?  By building this small piece of custom software the business can quickly learn and pivot if necessary or continue to build the platform. 

Build a partnership with One80 Services, and build the right product. We start by asking the important questions. 

Contact One80 Services Custom Development today and see how we differ from other custom development companies.  


, ,

Custom Software: Products vs Projects

Custom Software: Products vs Projects: Making a shift in technology projects and teams that focus on products rather that projects can be a seismic shift.

Stop thinking in terms of technology projects and begin the shift towards product thinking.

Many companies kick off individual projects with specific goals, timelines, budgets and resources.  These teams are tasked with a singular focus – clear the backlog and finish the project.  They rely heavily on the Product Owner to work with the stakeholders to determine features and priority.  They trust that the Product Owner is making the right decisions, and why should they ever question the Product Owner?  Scrum indicates that the Product Owner is responsible for the backlog and that the team is responsible or the execution.

Sometimes this is referred to as: Product Owner controls the ‘What’ and the Team controls the ‘How’.

A project is a planned set of interrelated tasks to be executed over a fixed period and within certain cost and other limitations.

This thinking is quickly becoming a limiting factor of organizations that are in highly competitive markets or industries.  Companies are finding that thinking in terms of a bunch of horizontal projects instead of vertical products is hindering their ability to adjust to ever shifting customer demands and to drive innovation.

Individual project teams are normally chartered to work set of deliverables.  Often these teams work in a limited vacuum blissfully unaware of other projects or company objectives.  This approach creates silos that makes it difficult to track and coordinate dependencies.  These silos generate gaps in knowledge, skills, and architecture platforms across the organization making it difficult for companies to shift project between teams without huge retooling costs.

The business dictionary has an interesting definition for product under it’s marketing category:

A product is a good or service that most closely meets the requirements of a particular market and yields enough profit to justify its continued existence. 

Building a product focused company required a shift in strategic and tactical thinking across the organization.  Companies must begin to empower teams to build products and services that meet current customer demand.  Teams must be allowed to shift priorities and to begin to innovate to drive customer retention and acquisition.  

software that allows them to identify what customer really want, and will retain and attract new customers, what they are will they will pay for.

Allowing a team to become Product focused required change in team dynamics.  The Team and Product Owner must begin to develop tools and approaches to developing software that allows them to identify what customer really want, and will retain and attract new customers, what they are will they will pay for.  Only when a company makes a shift in this thinking can they start to leverage the software to build a completive advantage.

Benefits to product focus:

  • Focus on Customer
  • System Scalability – efficiency of scale (services, web components, hardware…)
  • Consistency 
  • Quality
  • Modern software development practice
  • Building a better, more innovative product
  • Understand the customer – likes and dislikes, needs, wants, what they are willing to pay for, nice to haves, must haves…

Reach out to One80 to Ask us how we can help you make a shift to a product culture or for your Custom Software Development needs.

People Are Not Resources

I spend a lot of time working with Executives and Senior Managers.  Generally, in my very first meetings I ask about the company’s Products vs Project focus.  We then quickly transition to review team structure and stability.  During this process, we dive into current leadership structure, how work is organized and assigned, which roles are present on each team, and how project status and risks are reported.

I am often struck by the use of the word ‘Resources‘ to define people. Resources describe something that can be purchased, such as: servers, computers, photocopy machines and office supplies

People are not resources.  

Teams are living, breathing organisms comprised of people with varying personalities.  Teams must be approached in unique ways to ensure growth and survival.  By defining a team (or individual contributor) as a resource we are saying that the same homogeneous approach can be applied in each case.

Finding resources is not difficult.  We look in a catalog, we choose a product and we place an order.  Several days later, that resource shows up at the door. Ask any manager who has hired a new employee and they will tell you that finding someone to join a team is never that easy.  Retaining qualified people is also not easy.

We have all seen the meme: “5 ways to find and retain good employees”

  1. Create an open and honest work environment.
  2. Provide opportunities to grow and learn, and let your employees know there is room for advancement in your company
  3. Recognize and reward good work
  4. Encourage Innovation and Growth
  5. Allow people to do the job you hired them to do

These five points enphasis valuable insight into how to engage employees.  When managers ask me about switching to Agile and making a transition towards Servant Leadership, I always tell them that the easiest way to make this shift is to remove the mentality that people are Resources. Begin to think of your teams as unique personalities and tailor your approach to them respectfully.


Would you like to hear more about building and encouraging your teams?

Check out our Agile Leadership courses


The Pros and Cons of Custom Software Development Outsourcing

In our previous blog post, Custom Software Development Outsourcing vs Partnering, we review the reasons why you should consider partnering with a development firm over outsourcing the work.  This blog post will focus on more the traditional outsourcing model and review some of the pros and cons with an outsourced technology strategy.

Traditional outsourcing is referred to as the contracting or subcontracting of noncore activities to free up cash, personnel, time, and facilities for activities in which a company holds competitive advantage. Companies having strengths in other areas may contract out data processing, legal, manufacturing, marketing, payroll accounting, or other aspects of their businesses to concentrate on what they do best and thus reduce average unit cost. Outsourcing is often an integral part of downsizing or reengineering. Also called contracting out.


Pros of Custom Software Development Outsourcing:

The pros of outsourcing positively reflected by enterprises across industries include:
  • Reduced labor cost and quicker return of investment (ROI).
  • Allows companies to focus on core competencies while not being concerned about outsourced routine activities.
  • Reduces cash outflow and optimizes company resource utilization.

Cons of Custom Development Outsourcing:

When considering outsourcing, it is important to weight the disadvantages before any decision made. The following represents some of the cons experienced when outsourcing custom software development:
  • Possible loss of control over a company’s business processes.
  • Problems related to quality and turnaround time.
  • Sluggish response times coupled with slow issue resolutions.
  • Lower than expected flexibility and innovation.
  • 50% of employers report quality of their service providers and a reactive versus proactive attitudes are the most frustrating issues to deal with.
  • Language barriers and cultural differences. 
  • Reduction in employee morale.

By partnering with an Agile company rather than outsourcing, each of these cons, or risks, can be dramatically decreased or eliminated.  The Agile Manifesto and the Agile Principles, when applied correctly, directly challenge all the underlying symptoms which cause these problems.  

Contact One80 Services Custom Development today and see how we differ from other custom development companies.  



Talk to us Today




Agile Servant Leadership Assessment

Every agile book that you pick up discusses the topic of leadership on an agile team. One of the cornerstones of any successful agile implementation is the concept of servant leadership

Servant leadership was coined by Robert K. Greenleaf in “The Servant as Leader”, an essay that he first published in 1970.  The business dictionary defines Servant leaderships as:

Servant leadership stresses the importance of the role a leader plays as the steward of the resources of a business or other organization, and teaches leaders to serve others while still achieving the goals set forth by the business.

In fact, it is hard to imagine a successful team without self organization, accountability, and transparency.  Having Scrum Masters, Product Owners, and Managers with servant leader skills can make all the difference on your team’s journey.

If you are interested in applying Servant Leadership skills to agile-specific roles check out our courses page. 

In every agile implementation, I am asked, “How will I know who will make a good servant leader?”  My answer is always the same, “Everyone can be a servant leader – some people just may have to work at it a little more than others.” 

The next question I hear is, “What are the qualities of a servant leader?”

I have devised a simple test to help people identify servant leader qualities: 

Step 1

Write down the names of 4 leaders that you admire. These may be people at your current or previous jobs, community leaders, civic leaders, or anyone else that you look up to. 

Step 2

Write down 4 qualities that stand out for each of the leaders.   When you are done you should have 4 names with 4 qualities for each leader, for a total of 16 qualities.

Step 3

Choose and circle the top 4 qualities you think are the most important in a leader.

BAM! I will bet the top 4 qualities you have chosen are all qualities of a Servant Leader. Each of us already instinctually understands the qualities a Servant Leader must possess.  These are qualities we admire in other great leaders.  

Each person’s top qualities might be different, and that is ok.  This is a personal test to highlight the qualities we find the most important and the same qualities each of us are striving improve upon in our journey to become better leaders.  

So the answer to the question, “What are the qualities of a Servant Leader?” is this:  You already know what they are, you just need to look at the great leaders around you.

If you would like more information about leadership or to learn how One80 Services can help your company implement a Servant Leadership culture, check out our Agile Leadership or Leadership Conversation courses or contact us for more information.

Talk to Us Today

Custom Development: Outsourcing Partnerships

There is no disputing that custom development outsourcing can be cheaper.  You can hire development firms outside the US (offshoring) that charge half the normal local rates. 

If you are thinking about custom development outsourcing, you’re doing your business a great disservice if you don’t consider partnering. 

The most common reason for custom development outsourcing is the reduction in cost. The reality of cost saving are complicated with 30% of companies reporting that it’s an effective strategy to reduce costs; 55% percent say it’s somewhat effective while 15% claim that it’s not effective at all.

If you are thinking about custom development outsourcing, you’re doing your business a great disservice if you don’t consider partnering.  Partnering, in this context, is about building a long-term strategic relationship with a local IT vendor who will help satisfy your strategic goals.
Partnerships allow for two companies to sync core competencies, expertise, and efficiency of scale to help each other achieve long-term success.  Partnership can be established in many forms:
  • Short-term development efforts
  • Long-term support and maintenance
  • Ad-hoc hourly support
  • Equity based ownership

Choosing a partner to complement your company’s culture and objectives can be challenging.  However, when done right each company can reap benefits.

custom development outsourcing statistics

Custom Development Partnering Benefits:

  • Collaboration
  • Sharing the burden and potential risk.
  • Access to more skills, knowledge and experience. Partnerships provide for a wider skill base, complementary experience, and knowledge. 
  • Better, more effective decision-making. 
  • The ability to look at problems from many angles can help to achieve better, often more creative, and innovative solutions.
  • Flexibility to use company resources on the highest priority strategic objectives.
  • Resource reduction: shifting the burden of staffing professional IT personnel and allowing a partner to do the staffing to accommodate fluctuating IT needs.
  • Infrastructure: Shifts the burden of purchasing, maintaining, and supporting costly IT infrastructure to a partner.

One80 Services is ready to partner with you on your next project.  Give us a call today.

Talk to Us Today

Release Planning – Reducing Silos, Creating Understanding

Release Planning is becoming a controversial topic in the Agile community. Purest are saying that if you are doing true Scrum you should release working software often – as soon as an MVP is ready.  The Team should be releasing frequently in order to learn from their customers and users.  I agree 100% with this paradigm; however, on large scale projects with many teams, stakeholders, dependencies, and risks this can be difficult.


We work with many clients who are developing larger software projects. In organization with multiple teams and product owners, priorities can be to coordinate.  These clients are not large enough to implement a full Scaled Agile framework, so release planning sessions gain importance.

I recently facilitated a Release Planning session for an organization which took an interesting turn.  The meeting became less about writing Epics and Stories, reviewing velocity, and charting a path towards release success.  Don’t get me wrong, we definitely accomplished these tasks.  The more important lesson from the activity, however, was getting everyone on the same page.

I started the session by asking everyone in the room to quickly define the scope of the next release on a post-it note.  It was clear from other conversations I had with the people in the room that they had already completed dozens of meeting to define the release.  I figured this was a no brainer.

I received about 6 different visions.  Not just slightly different but COMPLETELY different.  How could this be, how could the dozens of meetings not have generated a scope plan?  Simple: Personal Agendas.  Everyone in the room had a different agenda and view point (reduce customer complaints, simplify architecture, upgrade platform, introduce cool features, etc.).  Planning had taken place in silos.  Each department had meetings to discuss scope, but no one had ever brought the silos together.

We took a quick detour and spent an hour defining scope by listening to each person’s ideas, priorities, and customers needs and wants. At the end of the first hour we had a well-defined understanding, which helped simplify the release planning and give the Product Owner and Team a cross-functional release target.

On large scale projects with many teams, stakeholders, dependencies, and risks – sometimes reducing silos and creating understanding before building a release plan is the simply the smartest way to go.

Talk to Us Today

Event: Writing good User Stories (ConAgra Sept 2015)

Agile writing user storiesOn September 2nd, ConAgra and One80 hosted another workshop in our Agile Basics series.

Nearly 50 people came together to learn about Writing User Stories.  It was a very productive and informative session in which we all learned from each other.

It’s exciting to see that so many people in the Omaha area are looking to learn how to write better User Stories!

If you weren’t able to make it to this workshop, feel free to take a moment and watch the presentation below.


Agile Visual Modeling

If you have idea for our next workshop or would like to host, please contact us.





If you are interested in our seeing our full list of great Agile courses click here.


Beware of Snake Oil: The Agile Tool Salesperson

There are some great Agile tools on the market to manage backlogs, track metrics, create visibility, and measure capacity & velocity.  These tools range anywhere from free to several thousands of dollars.  We have nothing against these tools, as a matter of fact One80 even partners with several of these tool vendors.

That said, we have seen an alarming trend in the project management world of using expensive Agile tools to drive process.  This trend doesn’t apply to just companies using Agile but it seems to be accelerating, and it goes directly against the Agile Manifesto.

People and Interactions of Processes and Tools

This new trend follows into two categories:

1Molding Agile, Scrum, or Kanban (you pick the mythology) to fit a software tool.

We see many companies pick a tool and then force Agile to adapt to the tool.  Now to be clear, I am not against software tools.  There are some great tools on the market that can help manage backlogs, track metrics, create visibility, and  measure capacity & velocity.  Each tool approaches Agile in a slightly different manner.  The DANGER comes when a company chooses the tool first allowing the tool to drive the Agile implementation.

We recommend that when starting an Agile journey, always start low-tech: Post-it notes, whiteboards, flip-chart, or excel.  There is no need to get fancy.  Allow your team to focus on what is important – The Agile Manifesto and continuous improvement.  Over time the team(s) will create an Agile approach that works for them.  The Enterprise will begin to learn how to scale agile and develop effective Metrics that actually drive value.  Once a stable Agile solution is established, then and only then, can a company begin its evaluation of tools.  This is exactly the process the One80 follows in our Agile Kickstart program.

2Using expensive Agile tools or frameworks to solve team dynamic problems.

Every implementation of Agile and every team has their own unique challenges. These challenges range from Team Dynamics, Communication, Cross-team Coordination, Scaling, Vendor Management, Change Management (the list can go on and on).

We have found more times than not the solution to almost all of these situations is staring you in the face. Just ask the team, listen to them, trust them, and they will solve 90% of the problems. Yes, they may need a good facilitator to guide them, but let the team self-organize, let the team build some information radiators , let the team us their retrospective skills.  After all, isn’t that what agile is all about?  Inspect and Adapt.


Talk to Us Today

Do you really need a Product Owner?

I recently was visiting with a potential client about the need for a Product Owner.  They asked: “How much time will the person assigned as Product Owner need to dedicate to this project?”

This is a very common question that we get from clients. The answer I give is always the same:  How important is this project to your organization?”

The response is almost always the same:  “This project is part of our strategic objectives and it is crucial to the company’s success, but we can’t spare a Product Owner for that much time.”

This is where things get interesting.

If a project is critical to your organization in any way, you must provide a dedicated Product Owner.

If you can not provide a Product Owner, your project is doomed for failure.

How can you not dedicate someone to work with the team to ensure that it delivers that highest values features, to inspect and adapt during the course of delivery? Why would you not want someone working with the team to help them understand each piece of functionality from the perspective of the users?


Why would you not want a Product Owner to learn about the new technology, to learn the advantages, disadvantages, and conceptually how all the pieces work together? Why would you not want a Product Owner to learn to communicate with the team as well as outside stakeholders?

Why would you not want the project to be a success?

Let’s state this in another way:

  • confused-faceYou would never plan a wedding by contacting a wedding planner, provide a few requirements, and then just show up on the big day.
  • You would never build a house by just approving architectural diagrams without doing continuous walk-thrus during the building process.
  • You would never trust a financial adviser to ‘get you to your retirement’ without constant planning sessions to review your needs, goals, and priorities.

No matter how much effort you take in creating a top notch, high performing, self-organized team, they will only be as successful as the quality of the Product Owner. Even the best teams need to understand the value stream of an organization. They need someone to help keep them on the right path. If left to their own devises, the team will build what they THINK is important rather than building something they KNOW is important.  This will most certainly not provide items of the highest value. Priorities shift, requirements change, objectives change, customers change – the team needs someone to help them understand all of this.

The company needs someone to protect their investment

– that is the role of the Product Owner.



To increase the effectiveness of your Product Owners, check out our training course, Scrum Master & Product Owner. Schedule a course for your organization now!

Talk to Us Today

Shake Up Your Daily Standup

The Scrum Guide says the following about the Daily Standup:

The Daily Standup or Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. The Daily Scrum is held at the same time and place each day to reduce complexity.

During the meeting, the Development Team members explain:

  • What did I do yesterday that helped the Development Team meet the Sprint Goal?
  • What will I do today to help the Development Team meet the Sprint Goal?
  • Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog. The Daily Scrum optimizes the probability that the Development Team will meet the Sprint Goal.

Daily Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making, and improve the Development Team’s level of knowledge. This is a key inspect and adapt meeting.

Agile Daily Standup-breaking out of the mold

We all the know the importance of the Daily Standup, but how many teams are actually gaining real benefits from the Daily Scrum or Daily Standup?  This ceremony is not meant to be a ‘Status Report’, but in reality that is exactly what this meeting has become.  If you have fallen into the ‘Status Reporting’ trap, then you may want to consider cancelling your Daily Standup all together or making some simple changes to shake it up!

5 suggestions to shake up your Daily Standup:

1. Extend the length of your daily scrum

Yes, you read that correctly.  If a team of 8 people all have to give an update at a 15 minute Standup, that is less than 2 minutes per participant to provide valuable information.  If someone has a question, then forget about finishing in 15 minutes.  Given the time crunch, team members will hesitate to provide all the information needed in order to allow the team to gain the full benefit from the meeting in favor of meeting the 15 minute deadline.  Stretch a little; give the team some extra time to collaborate – isn’t that what it’s all about?

2. Stop answering the three questions

We all know that a team should be limiting the Work in Progress (WIP).  Let’s say your team should be working on only three stories at a time: review each WIP story in-depth.  Allow each person who is contributing to that story to provide their insights.  Address all issues or questions, or put them in the parking lot for ‘Post Standup’.  (See number 3, below.)  Once you have completely discussed the WIP stories, ask if people are working or need to work on other stories.  This should avoid the schizophrenia that occurs with the round robin approach.

3. Create a post standup meeting

As the team is reviewing each story they will have in-depth questions, concerns, and ideas.  Use the time right after the Daily Standup to pair program or swarm around items from the Standup.  I like to keep a white board at hand and I write down  ‘Post-Standup’ items as they come up.  This gives everyone an opportunity to participate, including Developers, Product Owners and Scrum Master. There is no set time-box for Post-Standup-it is all about collaborating and getting stories to completion.

4. Allow the product owner to participate

If the Product Owner (PO) has questions about the story or wants to provide insight – let them.  Why Not? This is the time when the team is trying to make sure they are meeting the objectives of the Product Owner.  If the PO asked a detailed question that will take more that a few minutes, move it to Post-Standup.

5. Have fun

Banter a little! Life is too short to just jump into the heavy details of the Daily Standup or Daily Scrum.  Take a few extra minutes (see #1) to strike up conversations with your teammates.  Use it as an opportunity to do a little team building and get to know each other. Come prepared with an interesting topic and throw it out to the group such as “Name three things that you think will be obsolete in 10 years”. You will be surprised how far a little fun will go!

Talk to Us Today

Paired Programming Does Have an Impact

Nothing strikes fear into management more than the suggestion of Paired Programming.  They start envisioning multiple people sitting around one computer.  One person is working while the other is eating popcorn and reading magazines.  To be honest, I was once a ‘Pair Programmer denier’.

During a retrospective, a team brought up the idea of Pairing.  They even brought a video: www.mobprogramming.com

As a good Scrum Master I had no choice but to allow the team to at least try pairing for several hours a day.  I had every expectation that it would fail.  After one iteration the experiment was not a complete failure, and the team requested another iteration to work out the kinks.

After the second iteration, we were hooked.  Not only did pairing not fail, but our velocity began to increase, quality begin to improve, and the team started to spend even more time in pairs.

This blog post is a list of statistics that have I found that prove paired programming works, and my top 3 quick wins I received once I put paired programming into practice.


paired programming stats


Paired Programming Benefit #1: Communication

This benefit seems simple: ‘The team starts to work closer together, and communication goes up”.  However, the effects are more far reaching than that.  The team learned how to talk to many different personalities and skill sets.  They started to put our Emergenetics profiles into practice.  The team began to look beyond the ‘title’ of each team member and they began to utilize each team member’s vast talents and experience.  Our meetings per iteration decreased and our Retrospective and Demos became super-charged.

paired programming stats

Paired Programming Benefit #2: Quality Improvements

Quality on many levels began to increase. The team’s documentation quality increased while the number of pages per document decreased.  The number of bugs reported in production took a dramatic decrease while the amount of time needed for regression testing and hardening also decreased.  Job satisfaction increased as team members began to learn new skills by working closely together.

paired programming stats

Paired Programming Benefit #3: Self Organization

Planning sessions started to revolve around who would pair on stories.  The team started to self-organize in ways that I had not seen before.  The team started to ask questions like: “Who needs to learn this feature?”, “Who has experience…?”,”Who can assist with…?”.  As the team began to understand the ‘big picture’ they began to provide input on release planning and backlog grooming.  Their suggestions offered insight, innovation, and efficiency where there was none before.

What kind of experiences have you had with pairing? Positive or Negative? 

Talk to Us Today


paired programming benefits




Scrum Events – The too many meetings problem

Nearly every team that I have introduced Scrum into a new company someone has complained at some point about the duration of meetings in Scrum. I get comments like:

“Scrum has far too many meetings”
“What? A four hour planning meeting for a two week sprint!”
“We have so many meetings here, and now you are killing us with more meetings”
“I cannot have my team in spending so many hours in meetings”
“I am too busy”
“&(#* off, this is &$%# @

Here are the events in Scrum and the hours for each event:


A novice team may see these numbers as big and a lot of time put into each event, however if you follow the principle of inspection and actually take a deeper look into the timing; you may be a little surprised with some of the numbers.

For math purposes, I will be assuming an average 9AM to 5PM job with an 8 hour workday. I will also assume a Monday to Friday job as this is common in just about all the teams I work with.

Here is the breakdown of time spent on each event in a Sprint:


2% Retrospection

Teams should spend time inspecting their processes and practices and seek opportunity to do things better and faster. Without this inspection and spirit to adaptation is completely lost and the essence of agility non-existent.

2.5% Review and Feedback

At the end of the sprint it is important for the team to speak to stakeholders and seek their feedback on the work they have just completed. This risk management strategy helps correct misaligned objectives early by allowing the team show what they have built and the stakeholders to agree or to correct it. Not spending time doing this feedback will simply result in the wrong product been delivered to stakeholders and not to their expectations. This supports the entire belief in incremental and iterative development with regular feedback.

Next is reviewing upcoming work and allowing the Product Owner to demonstrate the health of the pipeline of work to both the team and the stakeholders. It is facilitates transparent communication to the health of the product, project and upcoming work.

2.5% Co-ordinating daily effort

Each day the team simply have a 15 minute event to plan who is doing what for the next 24 hours until the next Daily Scrum.

5% Planning and Design

The largest Scrum event is to Plan the next sprint and to do high level designs on how the work will be approached. Traditional development teams spent way more effort on planning and design and Scrum team have totally reduced this. Yet this event is the most controversial event where teams feel it is still to long.

One must agree with Winston Churchill “Failing to plan is simply planning to fail”. I personally do not think ask any team for 5% of their time to plan and design upcoming work is a big ask. Surely a professional should be able to recognize the importance to plan.

88% Available to do work

That’s a lot of time to get stuff done. I do consider refining as work.

Here are some more facts

1 hour per day (average) in meetings

If you look at it as only having a single one hour meeting per day on average, this is actually not much at all in the grand scheme of things.

It’s a time-box

A time-box is the Maximum time for an event, this means that if you can do it quicker whilst delivering the same quality; then please do it quicker.

If you are doing more meetings than the ones in Scrum, then you are doing it wrong and the organization has dysfunction that needs to be addressed.

Here is the math for the skeptics:


Author Brett Maytom is a Professional Scrum Trainer.

where is your time going


The Agile Snowplow Trap

I am one of those Scrum Masters who likes to talk in the abstract and with analogy. I find that it helps my teams to understand the concepts that I am attempting to coach. If I start throwing around a lot of Project Management terms, you know, ‘Risk’ ‘Contingency Planning’, ’Failure’, ‘Release Planning’, the team starts to shut down. I suspect they think, ‘There he goes again on another one of his PM things’, eyes glaze over, cell phones come out, people start daydreaming about their last golf outing. I have learned to avoid these types of coaching opportunities and instead try and put the concepts in terms that everyone can relate to.

Several months ago, I noticed that my High Performing team had started the bad habit. They were taking the stories that the Product Owner had provided, building the release plan and executing. With full knowledge that the Stories had not been broken down into sizable chunks that could be executed in a given sprint. Also, without helping the Product Owner to understand any additional Stories which may have been missed (I call these ‘Hidden Stories’).

The odd thing that continued to happen was that the team would even point the stories during Release Planning, as if they could be completed. From a Scrum Master and Product Owner perspective we thought we always had a fully formed Release Plan and Product Backlog, when in fact we had glaring holes.

In order to help the team understand the dysfunction that we had become trapped in, I developed the analogy of snowplowing (it came to me one day in the middle of one of our blistering Nebraska winter storms). I am not sure how snowplowing works in most neighborhoods, but in my neighborhood the snowplows blow the snow to the side of street (usually covering all the cars). However during times of extra heavy snow the snowplows actually start to push the snow forward and the trucks needs to work even harder to get the snow removed.

This was very similar to what was happening on our Product Backlog. When we would first start a release, the team would slide stories to ‘Done’ easily. However, when the ‘Hidden Stories’ started to surface, the existing stories got pushed into future Iterations to allow room for the ‘Hidden Stories’. Thus begins the effect of Snowplowing, or continuously pushing stories into future Iterations to make room for the hidden work.

During a Retrospective, I brought this observation up to the team. After much debate, the team determined the best approach to stop the Snowplowing. We took the time to redo Release Planning, write the ‘Hidden Stories’, repoint correctly. It was a great exercise and learning experience for the team.

Since that day, I have noticed that when these situations come up, and sometimes they can come up unknowingly during Sprint Planning, I hear the team say ‘That is Snowplowing’, and they retrace their steps to make sure they are not falling into the old traps.

Talk to Us Today

Work S.M.A.R.T.E.R. not Harder

We have all heard the phrase ‘Do more with less’. It is a common phrase is used to justify Agile. Executives equate that by transforming IT project management to Agile they will be able to do just that. While it is true that Agile can help an organization ‘Do more with less’, it can not begin to create results until organization begin to work S.M.A.R.T.E.R

S in smarter stands for Specific. You need to set specific steps and targets for the gradual achievement of your goals. Goals that are too general are easy to forget.

M in smarter stands for Measurable. You need to measure your progress with concrete iterations and daily milestones. Make sure you update your metrics often to ensure you’re on track.

A in smarter stands for Attainable. Give yourself goals that you can achieve within a given period of time. If you are forever striving for a goal, it may take too long and you could give up.

R in smarter stands for Realistic. If your team’s commitments are way out of the ballpark, you’re setting yourself up for failure. But don’t make the mistake of not believing in your team — it’s a fine line – trust that they can meet their goals.

T stands for Timely. Am I working on the highest priority item right now? So often, teams get caught up in the wrong activities. Always think: what adds value?

E stands for Exciting. Get your team excited about the vision of your project. Allow your teams to self-organize to drive innovation. Your teams will surprise you and attain results you never thought possible.

R stands for Ready, Set, Go!

Talk to Us Today
post =