Large Batch hand offs : Trapped in Wagile (part 3 of 4)

/by

This is part three of the continuing series of articles. In the first article of this series, I outlined three fundamental characteristics of waterfall system. In the previous article (part 2), I explained Phase-Gates and the unintended consequences when phase-gates encounter agile transformation efforts. In this article I will dive into Large Batch handoffs.

Working in large batches is based on thinking that handling large batch sizes during each phase optimizes:

  • Resource (people) Utilization
  • Quality : By use of people’s primary skill set
  • Reduction in rework
  • Decisions : through a broad holistic perspective

Expected System Behavior:

Fractal Nature:

At portfolio or organization level:

There are many active projects or initiatives, where in a majority of them have minimal or no impact on organization revenue/competitiveness in the current cycle.

At project implementation level:

Many active initiatives are bottlenecked by architecture group that is under high workload yet insists that all projects must submit their design for approval by the architecture group.

At task level:

Team members sign up for a few days of work and often do bulk check-ins that result in complicated build and merge issues.

Utilization Focus:

Most people are busy and have ample tasks to do. Often people are already behind and stressed about catching up with their work load.

Despite high utilization the organization system is struggling to get projects “done”. Management is stressed about active projects that never seem to complete.

With institutionalized busy-ness come weekly ‘red-yellow-green’ status meetings. Most participants turn on their zombie state and learn to check up on email under the drone of status updates.

Big Upfront:

Design and architecture for finality as opposed to changeability. This leads to big up front effort while designing and architecting. In subsequent phases – choices alternative to initial design, get eliminated by rule-of-thumb that any changes to requirements/design/architecture will require lengthy and delayed review and approval process and hence are not needed.

Large batch of testing and integration work gets pushed towards the end of the project. Delays during previous phased hand-offs accumulate and get transferred to later phases of product delivery.

Next Generation and Framework projects:

It is common to see “next generation” and “framework” proejcts creep up in these organization. Focus on utilization of people’s primary skillset has blinding effects on all other senses (including common sense). In these organizations lack of results is so rampant that leadership and their subjects desperately seek assurance and clamor to work on  “cool” projects. These are often labled “Next Generation” or “framework” implying some uber-wisdom that other’s less able can not attain. It is often that such Product development efforts get stuck within technical group who are perfecting and still not “ready” with master framework that will enable them to accept and develop features.

Unintended Consequences:

Decision concentration:

Imagine that on the first of each month one has to decide on their attire for every one of their work day for the rest of the month. Sounds silly! – But, with large batches organizations are doing some thing similar on a much grander scale. With large batch processing we are effectively concentrating all relevant decisions in a fixed time window. Not allowing for reassessment of product needs in light of new requirements or new design/architecture options.

Defect concentration:

With large batches, not only features but also defects get produced in large batches. An error in design choice or code implementation will be replicated until this area of product is tested or validated. This results in large area of code or functionality to be reworked. Working in large batches is favored by optimizers of functional process step (design/code/test) as this allows them to review holistically and make sound choices. But they always fail to account for holistic mistakes that they will also have and in aggregate cause huge expensive blunders. Limiting work in progress allows for learning from small less expensive errors.

Local Optimization:

People tend to optimize for their task/responsibility completion as opposed to working towards team optimization and quality throughput. With large batch of work at hand, people find it easier to optimize for large amount of design/code/test. This headphone-in-the-zone approach while maybe ideal for grunt work or isolated tasks – does not suit product development. Non-linear implications abound where in choices made by one team member disproportionately affects another team member’s options. There is no substitute to collaboratively flowing freely as a team through requirements ~ design ~ code ~ test aspects of product development.

Context Switching:

Large batch hand-offs are desirable on the premise that work handled in large batch sizes allows workers to optimize towards completion.

So when test is testing feature-(N), code is being done for feature-(N+1) and design is being done for feature-(N+2). When an issue is identified by test in feature-(N) others in code and design have to make a context switch from their in-progress feature (N+1) or feature-(N+2) to accommodate this unpredictable request. This often leads to:

  • larger than anticipated inefficiencies
  • Faulty assumptions implemented in code for feature-(N+1) that are not yet exposed while testing for feature-(N)
  • Quick fixes that do not address root-cause.

These lead to long-term instability and brittle product core.

Summary:

Delaying feedback and integration aggregates errors into blunders. Fear of small batch incremental development stems from inability to cope with interests of people focused on other important aspects of overall project. While there are many avenues for help and coaches available to show you the way (Many publishing practices in open public forums – one quick search engine query away). I have found that when it comes to change, those who are able to move to a better state – CARE!. Those who care about others interests and overall product always figure out ways to reach out, collaborate and problem-solve to make small batch sizes a reality in their organization. While the ones who don’t care, make excuses.

Proceed to final part four (Centralized Control).

Scrum Gathering Berlin – September 2014

/by

Recently we had the amazing opportunity to sponsor the scrum gathering in Berlin. Since our company Headquarters are also in Berlin, this was of course an opportunity we couldn’t pass up. Because we had the home advantage, many of us attended the Gathering (some who were there were not even in the picture, if can you guess who’s missing, let us know in the comments.)

agile42 Booth Agile42 group

In case you wonder what the towels are for, I guess you missed the reference to the Hitchhikers Guide.

Keynotes

This year the Scrum Alliance got some amazing keynote speakers, from very different backgrounds and who are not directly working in the Scrum Community, but their work has not gone unnoticed in the Agile community. Dave Snowden has been speaking about how organisations should stop working towards goals, but instead start looking for what is possible now. Don Reinertsen’s challenges some Lean dogma, and disqualifies some of them, and explains some are just not applicable in a certain context. Finally the closing Keynote of the conference was by Richard Sheridan, who shares a story on how he build a company based on the principles of eXtreme Programing on steriods.

Monday, September 22, 2014 – Prof. Dave Snowden

Enabling the organisation as a complex eco-system

Tuesday, September 23, 2014 – Don Reinertsen

Exploiting Uncertainty: Thriving in a Stochastic World

Wednesday, September 24, 2014 – Richard Sheridan

The Business Value of Joy

 

Visual Recording

During the gathering, the keynote and various other sessions were ‘visually recorded’ by the awesome Benjamin Felis. As an example you can see the visual recording of Don Reinertsen keynote below.

Other Sessions

There were many other great sessions, among them one from our awesome Bent Myllerup and Andrea Tomasino on Effectively Coaching Agile Teams.

Slides and other info on all the sessions at the Scrum Gathering can be found here.

Agile is everywhere

After hearing such amazing stories about Scrum the Hotel Staff of the Intercontinental Hotel in Berlin was convinced. See below the evidence of their daily standup.

red and black concrete posts

Phase-Gates: Trapped in Wagile (Part 2 of 4)

/by

In previous article, I outlined three fundamental characteristics of waterfall system. Phase-gates are the most distinguishable characteristic of a waterfall organization.

Recap

 Phases are are strictly linear sequence of activities to build a product or deliver a project. These activities are divided along process lines. Funding and progression to the next sequential phase is gated to ensure quality of deliverables handed-off between silos. Many decisions are concentrated at gating decision points. The Phase-gate approach provides an illusion of control, delaying feedback on product.

For example:

 Requirements → Design → Implementation → Verification → Maintenance

Gates or gating criterion accompany typical phase-gates. Gates establish GO/NO-GO decision points during the process and are intended to: Assert quality of work during each phase so that errors or mistakes are not propagated to downstream phases. Further funding of next sequence of phases is determined based on business context and organization readiness to move forward.

Expected System Behavior:

Fractal Nature:

At portfolio or organization level:
A phased-gated approach is undertaken where in typically a steering committee evaluates an ‘initiative’ or ‘project’ and goes through a serialized process such as:

Discovery → Research Product Concepts → Business Case → Test product Concepts → Gather Requirements and then so on until Maintenance.

At project implementation level:
Same pattern repeats itself where in:

Business Requirements → System Requirements → High Level Architecture → Detail Design → Implementation → Test → User verification → Release.

At task level:
This pattern is not as formally observed as in cases above. However you have probably experienced scenarios where a Developer is “waiting” on approval from Architect before he can check-in OR a case where a team member refuses to implement a well understood feature until the product owner writes down “detailed” acceptance criteria.

Early phases take longer than anticipated and later phases get squeezed. During each phase, work progresses uni-directionally from one phase station to another.

Uni-directional flow of work requires strong emphasis on getting things right the first time. Changes to requirements or design are never ‘welcome’ and always hard-fought.

Product development experiences unpredictable wait-states. Caused due to schedule slippage of predecessor phase and/or due to lack of readiness of subsequent phase.

People get organized in functional silos. Example, Business Analysts silo, Development silo, Testing silo etc. Each silo is lead by its respective manager who is responsible for meeting quality of phase deliverables and responsible for maintaining “busy-ness” of her people.

Unintended Consequences:

Feature filtering:

Phase Gate governance mechanisms concentrate a lot of decisions at gating points. During the early phases of requirements gathering (scoping) many features get filtered out. This is purportedly to limit scope for a release. In other words, business is allowed to be smart to come up with features in a concentrated period of time marked by requirements or product concept phas. All other times their are needs are considered as no good (stupid). This practice leads to selection and elimination of features with out any end user feedback. And also confines understanding of user needs to that time many months ago when steering committee held their “scope” meeting.

As your business context and user needs evolve, so do requirements from a software product. So an idea that may not be appealing at the start may become relevant later. Feature filtering leads to dominance of guess work in selecting features for future product releases. Guess-work that is trapped in stale understanding of user needs. No wonder a majority of features in a typical products never get used.

Local Optimization:

In waterfall systems movement through phases towards the end of the relay race counts as progress. But this perception of false progress at local phase level results in overall portfolio brittleness. During later phases changes in requirements and/or design requested by dependent project teams are aggressively throttled preventing meaningful progress for dependent initiatives.

Degree of influence of dependent teams is inversely proportional to the “progress” made by co-dependent waterfall team. Such systems lead to global sub-optimization at the cost of local optimization.

Root-cause solutions and Resilience:

Late in the development game, technical changes or changes in product requirements are not encouraged. Often deferring these updates to next scheduled release. Instead short-term fixes are implemented. Mindset of getting-it-right the first time often enforced via governance bodies through exhaustive gating criteria creates disproportionate impact from risk-event when the requirements or design or code was not right. Unfortunately in a waterfall mindset such events trigger needs for stricter gating controls, further perpetuating exponential fall out from errors detected in later phases. There is a fundamental misunderstanding of problem domain, within software system development (big or small, green or brown) and attempts to make error proof phase gates and implementing big-brother governance systems will never work. There are known-unkowns and unkown-unkowns. Software products for the most part are exploring in the unkown-unkonwns space. Resilience to errors is far more important than error proof gating systems.

Hidden loopbacks:

When bugs are discovered in testing phase, typically a bug is reported to developers who then have to apply fix. While officially the project is in testing phase, the testers are waiting on developers to apply fix before they can continue further. This hidden loopback drives false perception that downstream phase is taking longer since revisions/corrections to upstream work product is incorporated in downstream phases. 

This perception of “being stuck” in a downstream phase because of issues in upstream work, creates unwanted pressure on downstream folks (testers). Hidden loopbacks not only mask process bottlenecks but also damage relationships between the silos that are pitted against each other.

Innovation Killers:

Phases are innovation killers. Silos and focused functional work straightjackets creativity and rewards bureaucracy. People confined to interaction within their functional community will never learn to work with other functional disciplines. Cross-domain understanding and multi-learning are essential to process and product innovation. We improve in areas where we practice. Your organization needs exercise and practice in working with each other. People will not auto-magically “collaborate”. They need to practice this often, again and again and again (up and down, up and down, painting the fence) until they learn to navigate constructively through conflict.

Summary:

Phases and gates are explicitly and implicitly pervasive in organization mindsets. A serialized cause and effect mental model is comforting but never reflective of how work really happens when you get down to it.

Following process for processes sake is an example of being stupid on purpose. You would be surprised by how many people feel the organizational straight-jackets that you do. Reach out, collaborate, eliminate unnecessary phases and gates. You can iterate on your organizational systems to find your shortest path to project success.

Proceed to part three (Large Batch hands off) or four (Centralized Control).

The Expedition 42’s Guide to the Galaxy

/by

The official crew poster for the International Space Station's 42nd expedition parodies "The Hitchhiker's Guide to the Galaxy." It’s nearly too good to be true: you probably know that “42” in agile42 name is a reference to Douglas Adams’ The Hitchhiker’s Guide to the Galaxy and that Don’t Panic is our company motto.

We have therefore shouted with enthusiasm when we learned that the crew for the NASA International Space Station Expedition 42 (six of the bravest and most competent astronauts and scientints including flight engineer Samantha “Sam” Cristoforetti, the first Italian woman astronaut) had chosen a HHGG-themed poster for their mission and posed in full character group photo.

Good luck then, and Don’t Panic up there (but you surely won’t).

Trapped in Wagile

/by

Organizations that are attempting to transition to Agile demonstrate waterfall characteristics – residually or resurgently. Understanding these characteristics and learning to observe manifestation of these tendencies in organization systems will help you uncover impediments to your organizations Agile metamorphosis.

After reading this series of articles, you may realize that your organization is still being waterfall but thinks otherwise i.e., Wagile

In this article series I want to explore deeper into the “waterfall” label and lay bare the fundamental characteristics that make up such a system. And subsequently I will dive deeper into each characteristic to highlight expected systemic behaviors and unintended consequences that frankly should no longer be unexpected.

Any software development shop that practices Waterfall, will demonstrate these three fundamental characteristics:

Phased and Gated Approach

“In theory there is no difference between theory and practice. In practice there is.” – Yogi Bera

Phases are are strictly linear sequence of activities to build a product or deliver a project. These activities are divided along process lines. Funding and progression to the next sequential phase is gated to ensure quality of deliverables handed-off between silos. Many decisions are concentrated at gating decision points. The Phase-gate approach provides an illusion of control, delaying feedback on product.

Waterfall theory vs practice

In theory it is expected that an idea is sound, that it can be analyzed and designed. The developers and testers have to just engineer this into system which will be launched under warm summer sun. In practice(reality) people are not sure whether their idea will the “winner” that they want it to be, analysts and architects are puzzled and pull together a plausible solution. Developers and testers soon realize that the plausible solution is not really possible. So they work late nights to jimmy in one fix after another until the project gets launched too late and for too much. Phased and gated approaches are guaranteed innovation killers.

Large Batch Hand-offs

Champions of a holistic perspective want a detailed understanding of the project. Such understanding drives planning, enables optimization of labor resources, maximizes utilization, and reduces rework.

This paragraph above is more suited to be about a project that uses machines to punch holes in sheet metal. Not about a project that applies human knowledge and skills.

The real challenge is about controlling runaway batch sizes where, despite best intentions organizations attempting to move towards Agile methods are unable to keep and maintain small batch sizes, as a result accumulate work in large batches.

Centralized Control

Complimentary to Phased and Gated, where decisions are concentrated at ‘gates’, with centralized control, decision making authority is also concentrated within selected groups.

Know-how is not know-when. While a central control body may be able to collect all information about the state of a project or portfolio, by the time they get to make sense of this information the situation on the ground has often shifted. Delays built by default into information flows of centralized control organization systems. Only in hindsight  do decision makers know when they should have applied their know-how.

Command and control style management often manifests in organizations that have Centralized Control characteristics. In such organizations, decisions are always made by a select few. Organizational gossip is the primary means of getting real information and management lacks awareness of real problems on the ground. Project effort, “TPS reports” (bureaucratic paper work that adds no value) and tasks make little sense to people doing the work and managers consistently feel ill-informed despite many daily, weekly and monthly status updates. Most feel like a piece in a chess-game. Some carry the illusion of more power than others, but each are equally at mercy of the organization system complexity that plays them.

All waterfall organizations are not the same:

Waterfall as implemented in one organization is different from waterfall implemented in another organization. Think of these three characteristics as primary colors in RGB Color Model.Organizations differ in their waterfall-ish-ness due to differences in their emphasis on one characteristic over the other.

The same RGB model analogy is applicable to individuals – reflective of their mindsets. When enough people share similar mindset (knowingly or unknowingly) self-similar patterns get repeated over and over again. That is to say that these tendencies manifest themselves at all levels, from project funding to project release level to how organizations are structured. To draw your attention to these self-similar patterns at levels within organization work system, I will use examples and highlight these under sub-section ‘fractal nature’.

Summary:

No two waterfall organizations are the same. The three characteristics: Phase & Gate, Large batch and Centralized Control, are emphasized by each organization differently. The degree of emphasis that your organization places on one or more of these characteristics will determine the challenges that it will have to overcome in their agile transformation. In the next series of articles I will dive deeper into each characteristic highlighting the challenges that you should expect. Conversely if you observe the challenges then you can get closer to understanding the legacy mindsets that are impeding your organization’s transformation.

Proceed to the second part Phase-Gates, or jump to part three (Large Batch hands off) or four (Centralized Control).

Effectively Coaching Agile Teams at Scrum Gathering Berlin

/by

The goal of the workshop was introducing attendees to a more structured approach to coaching teams, which uses a framework developed by agile42, called the Coaching Structure. More information about out approach and Workshop material from Scrum Gathering Berlin can be downloaded for free.

 

The first part of the workshop focused on understanding what is coaching and what is not… and developed introducing the concept of keywords, and curiosity when listening to a person during a coaching conversation. We didn’t have the time to go through level of listening, but we moved on to presenting a strategy to create Powerful Questions, based on Karl Tomm approach. Participants engaged in one on one conversation, practicing the usage of powerful questions, using some cheat-cards as guidance, but very soon turning in to a very personalized way. This natural step happens thanks to the fact that participants learned a strategy to formulate questions, and weren’t exposed to a list of pre-baked questions, allowing them to use their own style and make the conversation more natural, and fluid.

The last step has been introducing the coaching structure as a tool to enable a more structured approach to team coaching. The first step is to create one Coaching Card. By focusing on observing a behavior, formulating hypothesis as of why that behavior is happening, and based on those, formulate a behavioral goal, that you want your team to achieve. Once that is done, you start identifying leading and lagging indicators, that would tell you if the team is moving toward the right direction.

The final step is to identify what are the coaching tools that as a coach you would use, to facilitate the team’s learning and accelerate the team’s improvement. Now in order to shorten the list of possible coaching tools, you would use first some intuition and experience, and ultimately, by experimenting multiple tools in parallels, and by measuring their effectiveness using the leading indicators. In this way you’ll be able to learn from emerging behavior, and decide to dump one tool or another, and even find out something completely new! By managing the boundaries with Leading Indicators and tools, you will be able to provide the team with stimulations that will encourage evolution and improvement. Co-evolving the coaching cards, by observing the team behaviors and the leading and lagging indicators.

You can find all the material of the workshop, and also the awesome graphic recording of the workshop in the following video.

The content of the workshop was a small portion of our Advanced Team Coaching Training program, that is going to start as public training at the beginning of next year…

Thanks for the great contribution and the awesome feedback! The ROTI tells it all :-)

Welcome Turkey!

/by

We travelled to Istanbul last month to meet the local community together with the new Country manager Ercan Küçüközen. The event has been really well organized and there has been quite some interest. Many different companies sent people to attend and there has been a very positive feedback. We have to thank AVEA one of our first customers in Turkey, since 2010, to have supported our initial event by offering to present the amazing results they have been able to achieve in the demand management since the introduction of Agile. Many local company are now looking at them as a reference point for agile transformation, and we are proud of having had a part in it.

An image of the presentation of agile42 activities in Istanbul last month

The official unveiling of agile42 in the country will take place in the next few months, but already Turkey has entered the calendar of our courses. In September coach Bent Myllerup will facilitate a Certified ScrumMaster training in Istanbul and more trainings will follow. For further information please contact [email protected]. We are already working with local coaches, which are now completing the development program, to reflect the standards of agile42 (which as you might have heard, are pretty high ;-) ) and are already engaged in customer projects, alongside with more experieced agile42 coaches coming from other European countries.

Loyal to our vision of supporting real Agile Transformation in the world, using our unique Local-Global approach, providing coaches who can speak your language and understand your culture, we are very proud to have started operations in Turkey, and we are looking forward to great further development.

Adventures in Europe

/by

IMG_5392 Denmark trainees

Shortly after joining Scrum Sense in February this year I started my journey to become a Certified Scrum Trainer (CST). The process includes co-training with other CSTs around the world, so that I can get feedback to improve and, once I am good enough, I can get their recommendations that are essential to acceptance. For the past week I have been lucky enough to travel around Europe and co-train with some of the top CSTs and CSCs (Certified Scrum Coaches) in Europe. It has been a wonderful experience for me.

 

My trip started in Copenhagen, where I spent a wonderful two days with Carsten Feilberg, a friend and an incredible tester. We spent time refining our workshop for Let’s Test Oz where we will be presenting on Communicating Complex Information in Sydney next Tuesday. We have been designing the workshop over mail and Skype for the past couple of months and being together once more re-enforced the Agile principle that face-to-face communication is the best kind. We have come up with a great design and I am really looking forward to our session.

IMG_5393 CSM Aarhus with Bent Myllerup

My next stop was Aarhus also in Denmark. There I met up with Bent Myllerup, a very experienced CST and CSC with agile42. I spent two days co-training a public Certified Scrum Master (CSM) class with Bent in Denmark. Lucky for me the course was delivered in English. We had eight participants and received wonderful feedback. I was able to train some of the modules and learned some new techniques from Bent. I love being in a fresh context, because I can always learn new things and see how different people understand and take in information. It’s also interesting to see the European adoption of Agile, the different industries that are beginning to understand the value of empirical process control and fast feedback loops, and  working with teams instead of individuals. Bent speaks about a truck factor which I thought was a novel way of illustrating the point of resilience. The track factor is the number of people in a team that, if they were hit by a truck or won the lotto and left, the project would have to stop. So if you have only one key team member that knows everything and that information is not shared in some way with the team then you have a truck factor of one. A higher truck factor is better than a lower one. What is the truck factor of your teams?

CSM in Berlin with Andrea Tomasini CSM in Berlin with Andrea Tomasini

From Denmark I went to Berlin. Berlin is an amazing and crazy city. I arrived early on Saturday morning. Half of the city hadn’t woken up yet and the other half hadn’t been to bed. I was lucky enough to get to explore and see some of the sights. Sunday evening I met up with Andrea Tomasini, another very experienced and talented trainer and coach from agile42. We ran through our course plan for another CSM class on Monday and Tuesday. I got the opportunity to see Andrea in action and to train some of the course modules. I really enjoyed the way that both trainers focused not only on Scrum, but also on how important it is to be Agile. Transformation is difficult and changing your mindset early on is important. It’s also interesting to see how many companies both in South Africa and internationally have similar problems. We had 20 participants from all different backgrounds from gaming to building of aeroplanes. Who said Agile is just for software?

CSM in Berlin with Andrea Tomasini CSM in Berlin with Andrea Tomasini

It’s amazing to see how many different contexts are interested in the principles and values of Agile and Scrum, and how many people are really keen and eager to learn. The Training from the Back of The Room approach also helps to encourage people to learn on their own and creates an atmosphere of excitement and energy.

 

All in all it was an amazing experience. I had the opportunity to work with some great coaches and trainers and to learn new things that I can bring home. I love how supportive and encouraging our community is, both in South Africa and internationally. This is a long and tough journey and I feel that this trip has really helped to get me to the next level.

 

I am looking forward to co-training the next CSPO course in Johannesburg with Peter starting 30 September. Maybe I will see you there. If not I’ll be speaking at the Scrum Gathering in Cape Town in October, or maybe I will catch you at Let’s Test in Australia next week!

Co-location, no matter what?

/by

It’s common sense in the Agile community that co-location of teams is beneficial and many people see co-location as a necessary condition to working in an Agile way. Ten years ago this was definitely the case. But is this still the case today, or has the world changed? Are there scenarios where maybe other aspects are more important?

Why do/did we see co-location as essential?

A team works closely together to achieve their collective goals. Close collaboration is a key for fast and efficient problem solving. It creates a dynamic where the performance of a team as a whole is more than just the sum of its team members. This applies also to the interaction between the Product Owner and the team. The whole idea of working with User Stories – which are short reminders of a conversation instead of full-blown detailed requirements, is the possibility to ask questions in order to clarify the non-written parts of the work. A decade ago this was thought of as only possible with co-located teams.

Since then, there have been a numbers of improvements, most notably,  the more reliable communication tools such as Skype or Google Hangout, which enable fast and easy communication exchanges with or without video. These are very helpful for the communication within the team and also to get feedback from the Product Owner. I have actually seen some teams that still make use of group chats even while being co-located, because they have found its  usefulness in certain situations.

In addition, Google-docs, Etherpad and other tools  allow distributed, collaborative writing of documents and code. Working closer together using screen-sharing has become more and more feasible.

Last but not least, tools like Agilo for Scrum provide close interaction with a task board. Immediate movements and changes on the board are visible on all open browsers without reloading, which is a big help during distributed Stand-Ups.

Agilo Scrumboard

Is this enough to work fully distributed?

Well at least it has become much easier to bridge the distance. I have worked with teams that were distributed over three time zones. While distance and timezones are still a challenge, I have even experienced environments where the distributed  teams outperformed the co-located teams. They were, in fact, more aware of their need to communicate. When considering a distributed team, in my experience, the time spent together, especially at the beginning, is one of the most important investments.

Co-location is still beneficial, but many companies have to make trade-off decisions.

For example, many corporations have different skills distributed over the globe. A trade- off between co-location and cross-functionality needs to be taken into consideration. In my opinion, it is much more beneficial to form cross-functional teams in such a case, than to stick to co-location. A lot of the challenges distributed teams face can be mitigated.

We should not forget that the world is continuously changing and we need to adapt to those changes.

Illustration by the author.

person holding white and silver-colored pocket watch

5 Reasons to Kill Time Sheets

/by

I subscribe to a newsletter from Projects at Work which I rarely read. I happened to open it this month and stumbled upon a gem.

 

5 Ways to Improve Time Tracking

 

It prompted this post…

 

5 Reasons to Kill Time Sheets

 

I have a strong dislike to time tracking, especially on software projects and here is why. 

 

1. Motivation of people.

 

The first problem that I have with tracking time is that it inherently sends the message to teams “We don’t trust you.” Even if this is not the intended message, it is the one that everyone hears. More often than not these metrics are used in bonus and performance conversations and used as punishment or reward. For this reason the inherent behaviour that it drives is that people lie, and to feel unsafe and untrusted to get their work done. How will your data be accurate if everyone is lying. If you want people to stop lying then change what is driving their behaviour.

 

2. Managing resources

 

Secondly time tracking implies “resource” management and people aren’t resources. I won’t go into detail on that. Rather, here is a blog post on why that is important. http://arbitrarymix.blogspot.com/2014/03/people-arent-resources.html

 

3. Individuals over teams

 

Thirdly this encourages working towards goals as individuals instead of as teams. If the end game is for people to work better as teams then this drives dysfunction rather than collaboration. If project managers and teams are collaborating daily, then tracking of hours to understand progress is redundant. There are also better ways to visualise progress, and encourage team collaboration and team work. An example would be using a task board to visualise the work and track progress. Less work in progress also encourages collaboration, limiting WIP encourages team members to pair and learn. 

 

4. Satisfying the need

 

Mostly it doesn’t address or satisfy the need. If the need is to understand how long a piece of work takes before a team is finished with it, then there are far better ways of getting this information than tracking time. Measuring a work item start to finish is better than measuring a person for 8 hours or 10 hours a day. Understanding how many work items are done is a better indication than understanding the number of hours James spent on project A. If James said that it was going to take 100 hours and he has spent 80 hours then he has 20 hours left, and so you believe that he is 80% done. That might be true but equally as likely is that James has just discovered that he is only a quarter of the way through. My experience is also that often the last 20% takes 80% of the time. 

 

5. Measuring Productivity

 

Do you want to measure profit or cost? If 3 pieces of work move through a pipeline in a week, that is a far more accurate measure of A: capacity and B: throughput. 

 

Productivity does not equal profit and linking the two together means that you focus on filling up capacity and measuring hours as productivity. Measuring productivity also implies that a team needs to fill up their capacity. The reality is that a team with 100% capacity is much like a highway with 100% capacity: a parking lot. 

 

What you don’t do is measure the rate of work through the system, or give that work space to move through quicker in future. Teams need space to move quicker and filling capacity is not likely to get that. Managing hours is also not a way to drive the right behaviour. If you fill up capacity then you won’t have space for innovation. If you focus on productivity you might miss focusing on profit.