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.

How to Plan Software : Six Ways to Improve Your Scrum Planning Meeting

So many Scrum teams struggle with planning on every level. Whether it be creating initial stories, decomposing stories, estimating stories or breaking them down into tasks. There is a notion that planning should be easy because we are smart, but the reality is planning is just plain hard. Teams tend to focus on estimation and how it is bad, meaningless or just a waste. It leaves them begging for someone to help them learn how to plan software.

Sprint Planning

Copyright Antgirl

“A goal without a plan is just a wish.” – Antoine de Saint-Exupery

Why do teams find things always take longer than expected? How can they spend an hour or even a full day planning one or two weeks worth of work to only find that they missed so much of the work necessary to actually complete the work? They scratch their heads because they just can’t seem to get better at planning.

Here are a few tips change how you plan software to become more effective and efficient.

  1. Draw. That is right, get up to a white board and draw out your thoughts. Not everyone thinks, understands or processes information the same way. Your brain works differently when it comprehends visually and when you express yourself through writing/drawing. Open up new neural pathways to think about the problems at hand.
    • Visualize the flow of how data, interaction or experience works.
    • Wireframe out anything visual so that there are concrete samples of how it works.
  2. Ask and answer the following questions. They will help guide discussion around easy to forget or often assumed interactions.
    • How do I get there?
    • What do I do when I am there?
    • What happens when I do it?
    • What happens if it goes right?
    • What happens if it goes wrong?
    • Where do I go when I am done?
  3. Verify that all the acceptance criteria/conditions of satisfaction have been covered.
  4. Task the work based on the information created in the above steps
  5. If you are estimating time on tasks make no single task greater than 2 hours.
  6. Commit as a team to the results desired from executing the plan

(ProTip: Use the above as a checklist before committing to each story)

Many people feel that planning is a waste. This may be true if there is no desire to understand the outcome or the path to get there. The more value placed on having some prediction of how things will play out, the more desirable planning becomes. It is important to note that all planning is a form of prediction. Predictions are not 100% reliable, but that does not render them useless by default.

The power of the plan lies the ability to commit to executing the intended results.  Not necessarily the path taken to do so.

“Unless commitment is made, there are only promises and hopes; but no plans.” – Peter Drucker

In the end. Do what you feel is right.

Calculating Lead Times While Waiting at the Motor Vehicle Department

I am fascinated with how systems work and how things are designed.  I put myself in observation mode as much as possible.  Today I had to head the Motor Vehicle Department (MVD) to get a few automobile titles transferred into my name.

I opened the door to a facility packed full of people.  The procedure here is that you stand in line to get a ticket.  That ticket is issued to you with a prefix.  The prefix is the group that you are assigned to.  I was assigned group J, which happens to be for issues involving title changes.  As I was standing in line I started to pay attention to how groups were called and in my head I noticed that it felt like each window was taking about 5 minutes to process.

When I received my ticket J616.  I realized that there were 18 tickets ahead of me.  It was 11:15 am.  I quickly did the math 18 tickets * 5 mins = 90 minutes or 1 hour and 30 minutes.  I should be done around 12:45 pm.  I had a lunch date at noon.  I didn’t call to cancel it immediately.  I figured I would calculate the cycle time for a few tickets and then figure out the lead time before rearranging my lunch plans.

I pulled out my phone and immediately started a timer.  The minute the first J ticket was called I hit “lap”.  First cycle time 5 minutes 11 seconds.  If I multiplied that by the remaining work 17 items and saw a lead time of 1 hour 28 minutes.  I texted my friends and asked if they could give me another 10 minutes to determine if our lunch plans were in jeopardy.   Two tickets later and the average cycle time had dropped to 2 minutes 43 seconds and the lead time was 40 minutes.  At that point I knew it would be cutting it razor close and so I opted to let them know it wasn’t prudent for me to hold them up and that I would be checking out of lunch.

MVD Cycle Time

Included above is the full source of data for my time at the MVD.   Cycle Time is the amount of time between completed tickets.  Running Time is the time of day at the cycle count interval.  Running Average is the average cycle time for all tickets completed through that cycle.  Lead time is the Average Cycle Time * Work In Progress (Tickets Remaining).  Est Finish Time is Running Time (Current Clock Time) + Lead Time.  Var From Reality is how much variance there was between that estimated time and the actual time completed.  You can see how calculating lead time using a cycle count can be used to predict completion time.

Some things I found fascinating.  The average variance against actual was 59 seconds.  The variance was never greater than 23 minutes.  My original estimates of 5 minute cycles wasn’t too far off from the 4 minute 12 second actual and the estimate of 1 hour 30 minutes was over stated as the actual was only 1 hour 11 minutes.

I know people tend to hate estimating, but I think it is because they are poor observers and can’t see the system as a whole in play.  Additionally, it only took me about 5 minutes to come up with the estimate and about 5 minutes to capture data and reconfigure my estimate based on reality.  What are some of your experiences playing with data to make predictions?