My Daily Stand Up Is Keeping Me From Being Awesome

Throw out the agile stand up!  Some people love Agile. Some people hate Agile. Few people have actually experienced Agile. There is plenty of Cargo Culting of Agile out there. At the end of the day it boils down to having the ability to “inspect and adapt” for survival. Survival requires improvement. Deliberate practice is the most tested way to improve. Deliberate practice requires metrics and measurement of performance of some kind.

I find most people don’t really want to be excellent. They just want to be left alone because they think they are already great or don’t want to put in the effort involved to improve. Those that perform at the top of their game tend to exhibit the following two behaviors.

1. They believe they could perform even better if they worked harder and more deliberately to remove weaknesses or improve strengths. They have a growth mindset.

2. They know they need outside help to improve. They often are surrounded by coaches/mentors that drive their performance. Want to get great at something? Get a coach.

7 Arguments Against Agile Ceremonies (Like Stand Up)

Recently I read “You don’t need stand up“, which is a well put together case against why Agile “ceremonies” just aren’t necessary. I believe it is well intentioned and echoes many of the arguments I have heard over the years. I used to call this type of philosophy “Sofa King Agile”. The belief being we are so fucking agile already that any process just slows down our agility. It helped that it also spells “So Faking Agile”. I now call it “Chaos Driven Development”. This variation isn’t driven by the superiority complex, but instead by the inability to see any value in process. Fostering organic development amongst trusted adults gets results. Why add anything else? The problem is that these anecdotal experiences don’t jive with all the science on productivity and growth.

So should you throw out Stand Ups, Retrospectives and other Agile Ceremonies? Let’s dive into the arguments expressed in the article.

1. We did this [stopped having ceremonies] and were successful. “We were an extremely productive team that responded to change and nailed every goal we set out to.”

What was the baseline of productivity? Did this approach improve the baseline? Has there been improved performance over time? Success by our own definition feels great, but it may be a complete lie. Imagine being a runner and running a 6 minute mile. That would feel pretty amazing for most people. You would better at running a mile than most people you know, but you aren’t even close to the same league as the best runners in the world (~4 minute miles). I set a goal for having a sub 8 minute mile, when I first started running. I hit it and I was ecstatic. My goal was achieved. I am a fool if I believe that makes a great runner.

2. Trello (or whatever you use) has to be kept in sync with what’s discussed in these meetings. It often isn’t. As the team grows this becomes even more complicated.

Physical boards largely remove the sync problem. If you aren’t using data during your stand up, you have room to improve. Information should be updated in real time during the stand up. If you are using all digital tools, maybe switch to a digital stand up? It is easy to evade pathways that increase accountability in the name of freedom. Don’t underestimate the importance in transparency of work outside the team.

3. Stand up ENCOURAGES plans to change daily. Lack of consistency is a great way to ruin developer flow.

The world changes pretty frequently. Daily doesn’t seem too invasive. Good days and bad days exist. Being able to interrupt and course correct is crucial. Imagine trying to lose weight without measuring food meal by meal, day by day and only relying on stepping on a scale every quarter to be successful. It may be possible, but not very likely. The same goes for software development.

4. Stand up forces every team member to be productive at a set place and a set time

If you want to go fast, go alone. If you want to go far, go together. I don’t think stand up require physical togetherness, but it does help. Set place is an self-imposed artificial constraint. Set time is also not mandatory, but doing them asynchronously has diminishing value. In order to collaborate effectively there is required time together. If a group can’t find 15 minutes of overlap in a day to coordinate work there is a bigger problem at play.

5. Extroverts thrive at stand up, planning, and retros. It’s no wonder that tech debt is such a common problem. Developers shouldn’t have to PUSH for tech debt to be addressed. Teams should operate at a sustainable pace.

I can’t even unpack this argument. It is feels more like a rant than anything else. Which is a shame because the other arguments seemed to be well thought out. Extroverts may thrive at certain ceremonies but that doesn’t mean introverts don’t add or get value at them. Implying that an introvert can’t work with others effectively seems dangerous at best. In coaching hundreds of teams and thousands of developers I have yet to find an introvert that wasn’t able to engage effectively in Agile ceremonies. Done properly,  planning helps protect, not hinder sustainable pace.

Developers should have to push against technical debt creation. Value creation is always a trade off.   Sometimes taking technical debt on makes sense. Sometimes it doesn’t. That’s a conversation that has to be had continually by all parties. Is technical debt bad. Yes. Do most companies wrongfully ignore it. Yes. Does that mean taking care of technical debt overrides all else? No. Are developers alone good at choosing how/when/what debt to remove in a vacuum? Rarely.

6. Why do we encourage problems to be discussed once a week? We should address them immediately, not just at retros.

If you are only discussing issues one time a week. You are doing it wrong. Retrospectives give a facilitated mechanism to dive deeply into tough problems and team dynamics that aren’t getting worked out in the day to day.   They are not meant as a container to sweep all problems into. Retrospectives are one of the things most teams do horrifically bad. The biggest room for improvements come in changing the system and human dynamics within the system. People regularly ignore this to their own detriment.

7. Sprints encourage iterative development. This sounds really good to people like me who strongly advocate small, concise, pull requests over long-living feature branches. But it’s not the same thing. Sprints encourage features over tech debt. How often have you had to advocate spending an entire sprint tackling tech debt?

Bad product management may prioritize features over technical debt, but sprints have nothing to do with it. You should have to advocate for what you believe is important. So should product. It sounds like organizational issues, not sprints are to blame here.

Let’s look at the additional break down of the arguments

Stop Doing Stand Up

Again this seems mostly like a rant surrounding technical debt. Does standup interrupt developers? Possibly. A small interruption is generally well worth the coordination benefits it yields. If you aren’t seeing coordination benefits you probably aren’t working as a team, but rather as a group of individuals. Stand ups aren’t useful for people working as individuals. If your stand ups are running longer than 15 minutes you have a problem.

I have seen no correlation to stand ups making a team communicate less. I have seen the opposite in my experience. About a third of the teams I have coached have one or more team member that is remote. It has never prevented stand ups from occurring. Teams that work poorly together remotely struggle with this more than those that already effectively work together with remote members. Technical debt has nothing to do directly with stand up or any particular Agile ceremony. Developers may feel less stressed without a stand up, but often a stressor is a good indicator for a looming problem or a motivator for performance. If stress free is the goal, you have already accepted mediocrity. Trust is a two way street. Most teams I have observed the members don’t trust each other completely. Stand up is a way for accountability among the developers to surface.

The remainder of the objection falls squarely into the “Chaos Development” model. The science just doesn’t prove this model out. People tend to not perform their best as free grazers. There is science that shows creativity increasing under a Chaos model. It may work well for research teams, but probably needs to be moderated for production teams. This is why you see many organizations doing 20% time etc.

Stop Doing Retros

The time to ask for help is when things are going good, not when they are going bad. The absolute right time to engage in couples therapy is when things are good not when they are in destruction mode. Your relationships, personal or otherwise should always be improving. That requires work, reflection and outside assessment.

If you can’t take thirty minutes to an hour every week to reflect, you are already running at an unsustainable pace. Perhaps that is why there is so much focus on the technical debt theme? If you are waiting to address problems only at a retrospective you are waiting too long. There is no need for stickies or sharpies to reflect. They can help from keeping things stale.

Some of the projected questions. That the article thought might get asked.

“How will I know what to work on?”

Nothing here seems out of place. The “Best” option could be a smell if it’s invoked frequently, but more than healthy in moderation.

“What do I do if I’m blocked?”

These all seem pretty sane to me, albeit a bit specific technology focused (trello, slack, etc)

“How will I track the progress?”

It is okay to ask everyday. Multiple times a day. A good team broadcasts so you don’t have to ask. I think a fundamental flaw here is that progress only matters to the team. It should matter to all stakeholders in the outcome of the work.

“Hold on. We totally handle tech debt and we do stand-ups!”

It is pretty common this happens. Any organization that doesn’t value quality isn’t going to prioritize preventing or eliminating technical debt. That has nothing to do with stand ups or Agile.

Conclusion

Question everything is brilliant advice. Start with am I the best at what I do? Is my team the best at what they do? Is my organization the best at what they do? How do I help get all of us to our best?

My advice to teams is that you are not nearly as good as you think you are. Discipline and habits are the best paths to performance increase and skill building. Having an objective outside party pushing you is the most effective way to accelerate performance. Process done well goes a long way. When you get to the point where you don’t need any process, you will find that you crave it anyways. Think Miyagi. Daniel san paint the fence. Wax the car.

We tend to resent that which we don’t fully understand. Are stand ups necessary to be awesome? Hell no. Until you understand what makes them powerful, you probably shouldn’t dismiss them.

The Path to Immediate and Unanimous Team Decisions

Digging a Hole / Copyright Jay Wood

Digging a Hole / Copyright Jay Wood

The Tanga team uses the Decider Protocol, part of the Core Protocols fromSoftware For Your Head by Jim & Michele McCarthy, which is a great way to move a group immediately and unanimously towards results. Sounds impossible doesn’t it? Part of the reason it is so effective is it removes discussion and gets to the heart of what it is that is keeping people from committing to moving forward. A bias to action so to speak.

How does it work?

It starts with someone proposing something. A very simple, concise and clear something. Immediately followed by people stating their level of ability to support the proposed action via vote. Voters, using either Yes (thumbs up), No (thumbs down), or Support-it (flat hand), vote simultaneously with other voters. Voters who absolutely cannot get in on the proposal declare themselves by saying “I am an absolute no. I won’t get in.” If this occurs, the proposal is withdrawn.

What is the difference?

People new to the protocol often ask what is the difference between Yes (thumbs up) and Support-It (flat hand) or No (thumbs down) and Absolute No.

Historically I have used the following to illustrate “absolute no”.
An absolute no, should be used only if there is nothing to do to get you in. Example, “You propose we rob a bank to fund our startup. 1.2.3.” I might be morally opposed to theft so am an absolute no. Nothing can justify to me robbing a bank. However, I might hate banks and be totally fine with that but only if it isn’t armed robbery, because I hate guns. Thus, making me a thumbs down, to get me in we can’t use guns.

I have used this to illustrate “flat hand”.
If “I propose lets dig a six foot hole. 1.2.3.” and you say flat hand. If I hand you the shovel to be the first to dig, you can’t say no I didn’t really want to dig.

An easy way to remember.

Our team made the following humorous matrix which I quite enjoyed.

If “I propose lets dig a six foot hole. 1.2.3.”

Thumbs Up means I am so eager to dig that I will fight you for the shovel.
Flat Hand means I will take the shovel if you hand it to me and start digging.
Thumbs Down means I won’t take the shovel unless something changes.
Absolute No means I would rather you hit you with the shovel, than start digging.

Please remember hitting people with shovels is not polite. Please refrain from doing it often.

Sunday Book Review : Getting Real by 37 Signals

Getting Real: The Smarter, Faster, Easier Way to Build a Web ApplicationGetting Real: The Smarter, Faster, Easier Way to Build a Web Application by 37 Signals

My rating: 5 of 5 stars

David and Jason were ahead of their time. Preaching a more simple way. There were others at the time talking about doing things different, but these guys were making it real. A lot has changed for them since they wrote the book, but a lot in the industry has stayed the same. Looking forward to another young, hungry company to show up on the scene and rewrite some more rules. Getting even more real. We could use it.

View all my reviews

Sunday Book Review : Remote by David Heinemeier Hansson

Remote: Office Not RequiredRemote: Office Not Required by David Heinemeier Hansson

My rating: 4 of 5 stars

I tend to find myself repeatedly finding I agree a lot with Jason and David even though I struggle to identify with them. I thought for sure this book would piss me off to no end. Mainly because I think that physical interaction is so important for success. However, they hit the topic pretty eloquently. They highlighted the right things about what is amazing when remote work is done right, but acknowledge that some face time and presence (head gap) is so very important. I suspect this book is powerful as a cultural wake up to many of the industrial minded managers out there that struggle greatly with effort versus results.

View all my reviews

Sunday Book Review : Antifragile by Nassim Taleb

Antifragile: Things That Gain from DisorderAntifragile: Things That Gain from Disorder by Nassim Nicholas Taleb

My rating: 5 of 5 stars

Fantastic book. Challenges everything you think you know about how things work. Economics and statistics turned on their heads and seen through a new light. Nassim has done a fantastic job of asking the right questions and pushing assumptions taken for granted.

View all my reviews

Sunday Book Review : Scrum Mega Pack by Paul VII

Scrum Mega Pack For the Agile Scrum Master, Product Owner and Development TeamScrum Mega Pack For the Agile Scrum Master, Product Owner and Development Team by Paul VII

My rating: 4 of 5 stars

This book is a group of seven books on the topic of agile methodologies from the author. The first “The Power of Scrum” does a good job providing some history and then covering the rules and practices to get started using Scrum. It’s like a Certified Scrum Master class in book format.

The second “72 Reasons Why Scrum Works” breaks down the roles and practices in a consumable format of background then reasons.

The third “Scrum Checklist” provides quick checklists for common ceremonies. I get worried that people that follow checklists get a bit prescriptive and don’t tend to grow, but for someone just starting these are a great help.

The fourth, “Scrum of Scrums” I could have done without. I am find them in practice to be mostly non-effective and propagate the notion of scaling in the wrong ways.

The fifth, “Scrum Tips” was a nice addition, but felt kind of jammed in.

The sixth, “How to Meet a Project Deadline”, had some practical advice that helps confirm that it was written by a practitioner and not a theorist.

The seventh, “The Kanban Guide” was a bonus that did a rather reasonable job of explaining Kanban. Normally I would say this doesn’t belong in a Scrum book, but because it was brief it was a nice way to expose someone wanting to learn more about Agile frameworks and methodologies to something that is compatible with Scrum.

The short nature of this book (under 200 pages) and its nice indexed format makes it great introduction for someone wanting to take a stab at Scrum, not to mention it is suitable for a reference for those currently already practicing as well.

Don’t take my word for it though.  The author offers some free chapters as part of his Free Scrum eBook.

* disclosure: I was provided a free copy of the book by the publisher, but I was not compensated for reviewing it.

View all my reviews

The Difference Between Influence and Manipulation

I was listening to an episode of Partnerships & Possibilities a while back and got to thinking about influence and manipulation.  Here are some of my thoughts.

The difference between influence, positive persuasion and manipulation.

Manipulation is me trying to get what I need.
Positive Persuasion is trying to help you get what you need while still trying to get what I need.
Influence is me helping you get what you need.

How would you define the differences?

Face to Face for Remote Team Members

Seeking Presence

Trying to do Agile practices on teams with remote team members is always a challenge. Especially when there is only one person on the team that this not physically co-located with the rest of the team. It is easy to feel disconnected from the rest of the team and even simple interactions feel painful. When you are the person left on the end of the phone after everyone else has left the room, asking if anyone is there, it is hard to feel valued. Digital tools for process management and video conference rooms are a good step, but they still leave a lot to be desired.

Virtual Team Member

Virtual Cookie Sharing.

Finding Face to Face

If we look at the Agile Manifesto‘s principles we find:

 “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

So how can we do that on a team with a single member that works remotely?

One solution I have seen that works very nicely is an iPad Mini plus a Nootle iPad Mini Flex Stand. This allows the team to pipe in the remote person to the iPad mini and have as close to face to face communication as possibly with out being physically present, with them all the time. The brilliance is that it is completely mobile. If the team goes to stand up they simply pick up the iPad and walk with the person to the standup. They can pass the person around as the token or prop them on the wall or a shoulder. When going into a meeting room for something like planning or retrospectives they simply put the iPad on the chair and the virtual member sits like everyone else. If they decide to take a team lunch no worries they just take the team member with them.

Recently, I caught a team using this solution trying to feed their virtual team member some home baked cookies that someone brought in to share with the team (see above photo). As you can see it doesn’t solve all problems, but it sure helps some with presence.  You may miss freshly baked cookies, but at least you will still feel like part of the team.

What is the Difference Between Scrum vs Kanban?

What Process is Right For My Team (Scrum vs Kanban)

I see a lot of new teams search endlessly for the best process for to use.  They tend to ask what is best for us?  Which usually devolves into Scrum vs Kanban. I am firm believer in experiencing them to understand, but one could argue you have to start somewhere.  For those seeking here is a very brief quick side by side view.

Copyright Klean Denmark

Copyright Klean Denmark

Similarities Between Kanban and Scrum

  • Both are Lean and Agile
  • Both use pull scheduling
  • Both limit Work in Process (WIP)
  • Both use transparency to drive process improvement
  • Both focus on delivering releasable software early and often
  • Both are based on self-organizing teams
  • Both require breaking the work into pieces (decomposition)
  • In both cases the release plan is continuously optimized based on empirical data (velocity or lead time)

From Henrik Kniberg’s “practical guide” comparing Kanban vs Scrum (pdf).

Quick Feature Comparison

Kanban Scrum Hybrid
Daily Stand-ups No Yes Yes
Artifacts None Backlog, Current Work, Burndown Charts Current Work
Metrics Lead Time/Cycle Time Velocity Lead Time/Cycle Time
Demo/Review Not used Required Optional
Skill Sets Specialized Allowed, Cross-Functional Optional Cross-Functional Prescribed Specialized Allowed, Cross-Functional Optional
Iterations Optional (can be event driven) Yes Optional (can be event driven)
Commitment No Yes (Per Iteration) No
New Work Prioritized Immediately (Optional) Prioritized at Sprint Planning Meeting Prioritized Immediately (Optional)
Retrospective Not used Required Optional
Work Decomposition No Size Limit Limited to fit within Iteration No Size Limit
WIP Limiting Per workflow state Per sprint Per workflow state
Estimation No Prescribed Optional
Work Visualization Board is persistent Board reset every sprint Board is persistent
Defined Roles None Product Owner, Scrum Master, Scrum Team Product Owner, Scrum Master (Optional), Scrum Team

How do you define your Bootedness?

Defining Bootedness

Julia Ivashina recently asked a very profound question of “How do you define your bootedness? **

She defines it as “the degree to which I master to exhibit rational behavior in situations where spontaneous reaction used to be my first response.”

One person framed it as, “for me it’s about living the Core Commitments: can I say I was true to them, all of them, at all times?”

Another pondered, “The aspirational goal is to behave according the the Core Commitments and fall back to Core Protocols when under stress… without being consciously aware of both.”

Another put it as, “At an individual level I agree with unconsciously following the Core Commitments and Core Protocols. At the team level have we internalized everyone’s Personal Alignment, signal, and response.”

Finally someone said, “Greatness! Bootedness = greatness.”

Copyright James Vaughan

Copyright James Vaughan

Individual Booting : The Current Metaphor

I like metaphors. One thing that appeals to me about the Core (Commitments and Protocols) is that adopting them is expressed in the metaphor of software programming. That your mind is like a computer. The core is a set of instructions that can run on your hardware to give you better and more consistent results. The reference to “booting” is loading the core operating system.

Network Booting: The Future Metaphor

So I prefer to express my “bootedness” by extending the metaphor. In today’s world of computing, the computer doesn’t matter much anymore, it really is the network that matters. Think of how most of your data and applications don’t live on the device itself. The power is allowing any device (node) on the network to access the power of the collective (the network). In 1985, a computer with an operating system and few applications was pretty incredible, but it had limited functional use to most people. Plus, they were not in abundance and very few people could wield them or use them.

Fast forward to 2013 and most of the world has access to a computer of some kind (think mobile devices), connected to a network that is extremely useful. The Internet is largely responsible for this because it set out a number of protocols to define how devices (nodes) can communicate. Additionally, massive cultural shifts about how we think about the power of computers  and freedom to interact happened (see Free Software Foundation, Cathedral and Bazaar). We moved from thinking the computers processing power was important to realizing that leveraging it as a tool to augment our qualities as humans could be much more effective. Think of what 2025 will look like…

Abundant Greatness is Coming

Currently the Core seems to be in 1990 in that is has provided a great personal operating system for people to connect on a Local Area Network (team) to interact. It is on the cusp of installing the network stack that will allow those nodes to flourish and expand. While challenging cultural assumptions that will allow humans to flourish.  Bringing the power of computing to the masses instead of the few.

Defining My Bootedness

I would define my “bootedness”, by my ability to be using the core effectively enough to interface with other nodes and advance network discoverability techniques to rapidly add additional nodes and leverage the network effect that it affords.  Exhibiting the highest integrity in reconstituting culture in ways to allow new ideas for humanity to be explored.

Yeah I know I am crazy. So what. The alternative is being normal.

What is the Core?

** What the hell is this booted crap?

In an effort to create teams that are effective at delivering every time Jim and Michele McCarthy with the help of other’s have defined Core Commitments. Agreeing to these commitments constitutes as being booted. As you can see, while simple they are extremely difficult to adhere to. When one finds themselves struggling they can lean on the Core Protocols to help them through.