5 Things Learned From Steve Jobs

Last week, I (virtually) attended the Lean Startup Conference and heard Guy Kawasaki – former Chief Evangelist at Apple – speak about 10 things he learned from Steve Jobs. Below are the 5 that caught my interest, along with some of my thoughts…

1. Customers can’t tell you what they need (you need to help them figure it out)

I think it is important to keep in mind that building the right feature takes collaboration and communication. This is similar to how a Product Owner presents a user story to the dev team and then there is a discussion to clarify points, add acceptance criteria or discuss why another approach could be a better idea.

2. Changing your mind is a sign of intelligence

This is very much in line with Agile thinking, which is why we work iteratively and incrementally and why continuous improvement through inspecting and adapting is so important.

3. Engineers are artists – treat them like artists

Just like an artist, engineers need space to be creative and innovative (no micro-managing). They also need time to work on their craft, for example, time to refactor so they are not introducing technical debt.

4. Innovators ignore naysayers

There are many reasons why people will say something can not be done. Perhaps they don’t understand the vision, maybe a particular idea threatens them or they don’t like thinking outside the box.

5. Some things need to be believed to be seen

Guy explained this as the idea of sometimes people won’t take the time to see something until they’ve been convinced of the idea. So, really understanding the benefits of a feature, being persuasive and convincing people of the idea many times is the first step.

Please let me know what you think.

Teamification: Agile Team Self-Selection

Earlier this year, while consulting as an Agile Coach, I was involved with an interesting experiment. The experiment asked individuals to self-select into software development teams. Team members would be allowed to choose what products they worked on and who they worked with. The event was called Teamification Day.

I had never done anything like this, so I was excited and also interested to see the process and results. A lot of effort went into preparing for the event. The Agile Practices group – which I was part of – took the lead by designing the event and communicating information.


Each work package (epic or larger) had an assigned Product Owner and dev lead. The PO and dev lead worked together to design a presentation that explained their work package. This would be used on Teamification Day to educate and recruit people to their team.

Each pair also had a board that would later be used to indicate interest in a specific work package and would eventually indicate the final roster for that team. This board contained valuable information, such as:

  • Standard constraints: The required makeup of teams (ex. 3-5 devs, 1 PO, 1 Agile Coach)
  • Team is able to deliver end-to-end solution
  • Where the team would be co-located (Chicago, for example)
  • Team information: Name, value stream and work package
  • Skills desired: Ex. One FE dev, two BE devs, UI/UX and also specific knowledge if necessary (Elastic Search, Java, Kafka, Nifi, Selenium, etc)
  • Team adjustments: After each round, teams would use this space to identify what they still needed or what they have too much of

The Agile Practices group created the boards and then had a couple of dry runs to see how it felt and what issues we thought needed to be addressed. There were a handful of issues and ideas – ranging from ‘will the areas be too chaotic with so many people and so many questions?’ to ‘do we need flags to indicate the team’s location, whether the team is fully formed or not fully formed?’. The goal of this event was to allow roughly 200 people to learn about 25 different teams, ask questions and then choose their own team – so we knew there were going to be obstacles.

Curiosity Market

On the morning of Teamification Day, there was breakfast – along with excitement and anticipation – in the ballroom. After some short messages from various leaders, the Curiosity Market was opened. The Product Owners and dev leads stood by their booths and pitched their work packages – explaining what they would be working on, why people should be interested and exactly what kind of team they were looking to form. The room sort of resembled a science fair.

Since there were so many teams, several rounds were run and the time slots were staggered – with some presenting and others taking a break – to give everyone an opportunity to get the information they desired. As is typical with many Agile events, the law of two feet was encouraged to allow people to move around and do what made the most sense to them.

Team self-selection

Following the Curiosity Market was lunch. The Agile Practices group discussed how the morning played out and went over last minute coordination details for the afternoon. We discussed that despite (what we perceived as) a successful morning, the afternoon would be more complex. Anything could happen as people started choosing teams. However, we had discussed possible scenarios and were armed with techniques to facilitate various situations.

As the self-selecting portion kicked off, some teams were formed quickly, as there were some individuals and groups who had previously discussed where they would like to be. The rule was that anyone could put their name on any team board – even if that team ended up having 15 people who wanted to be on it. After a couple of rounds, most of the teams were squared away, but there were some teams who had too much of one skill and not enough in other areas. The event facilitator asked teams to call out what they needed – for example, ‘we need two front end devs’ or ‘we are short one tester’. At that point, teams would know where the gaps existed and could go discuss and recruit people to help complete the team.

After a little more discussion and pitching from Product Owners, all the teams were formed.

Post team self-selection

Months after the teams self-selected, things seemed to be going very well. Individuals seemed happy with how things turned out and in a recent survey, the self-selection process was called out by many as a positive. There were only a handful of people who did not get one of their top choices and providing the freedom to choose your own destiny was appreciated. Of course, not everything is or was perfect – there were a couple of people who have been traded to help better align teams and when teams moved on to different work packages, the work was not the same, which was a little disappointing for some.

Another interesting idea that has been rolled out are job boards. A job board is a place where teams can advertise that they are looking for a skill and others can view the board to see what team they would like to join. There are certain constraints – for example, people need to be on a team for 3 months before moving – but people will also be allowed to switch teams if they’d like.


Overall, I am grateful to have been a part of this self-selection Teamfication experiment. By most measures that I see and hear, it was a success. It provided the freedom and autonomy for people to choose teams for themselves, which conveyed a message of trust and accountability. Self organization was center stage in this experiment and it proved, to me, that empowering individuals can be a strong force.

Being Flexible With Agile

After being involved with many Agile teams across a wide range of organizations – one thing is certain: each group will have their own style and flavor. No organization – whether a startup or Fortune 50 company – or team – distributed or collocated – will be the same. And in my opinion, that is a positive thing that adds value – not only to that specific situation, but to the Agile community as a whole.

The Scrum Guide, Agile Manifesto and other bodies of knowledge provide guidelines to follow, but flexibility is necessary in order to meet the needs of a particular project or client. Let’s face it, if teams aren’t flexible and don’t adapt to a given situation, there are times when nothing would get done. And typically, the goal is to produce working software, not to be in compliance with the Scrum Guide.

I have met those who are a militant about following the Scrum Guide to a T and any deviation is perceived as an act of war. Typically, I have found that sticklers are new to Agile – in the Shu phase of Shu-ha-ri. I will admit that when I began learning and applying Agile, I tried very hard to stick to the “rules”. However, I learned a while ago – after being exposed to various teams, organizations, levels of Agile experience, clients and situations – that being flexible with the application of Agile methodologies is important and probably a necessity.

The more experiments run and ideas tested only add to the amount of knowledge circulating throughout the web, conferences, Meetup groups and impromptu conversations. One of the great parts about Agile is the agility that it provides – the risks taken, the lessons learned, the nonconformity.

So how about you – do you strictly adhere to the Scrum Guide or do you tailor your approach to the specific situation? What are the pros and cons?

User Stories – Size Does Matter

Agile User Stories


No matter what team I’m a part of or what meeting I’m in, the topic of smaller user stories is regularly broached. The reason? Because it is really important. At the same time, smallerizing stories can be quite challenging. However, as challenging as it can be, it is well worth the effort. Here are some reasons why I think it is beneficial to create small user stories.

Small user stories are more clear

When stories are large, there is more information contained in the description and more acceptance criteria to be considered. Sometimes this can be too much to wrap your head around. For example, when there are about three stories worth of information contained in one story, it’s harder to understand the scope and chances are that there will be multiple dependencies introduced. When stories are small, they are easier to understand which allows you to focus on what is right in front of you.

Small user stories are easier to estimate

Going hand in hand with smaller stories being easier to understand is that smaller stories are easier to estimate accurately. Would it be easier to guess the weight of an elephant or a cat? I recently conducted a small survey asking people to estimate those weights and each time the estimate for the cat is much, much closer. Try it yourself. You can also see this in the Fibonacci sequence that is commonly used in Agile estimating. As the numbers get larger, there is more room between them which indicates more ambiguity and less precision. 1, 2, 3, 5, 8, 13… these numbers are all pretty close to one another… 21, 34, 55, 89, 144… not so much.

Small user stories introduce less risk into the sprint

Have you been part of a team that had a 21 point story carry over to the next sprint? It was almost done, but not quite. At the sprint review, the stakeholders are now a bit disappointed because they were hoping to see that new checkout flow they’ve been dreaming about for the past two weeks. Imagine if the team had broken the story out into 4 or 5 smaller stories, for example. The stakeholders would have loved to see how the user can add an item to their cart and then add their credit card, even if they didn’t get to see the confirmation screen and email. But now they are sad and wonder why they attended the review in the first place.

Small user stories increase the workflow

Maintaining a steady workflow is important to help the team get in a rythym and avoid bottlenecks. Perhaps you’ve witnessed a large user story stuck in progress for over a week while Johnny QA is twiddling his thumbs and tapping his foot just waiting for the chance to find those bugs. Smaller stories lead to a better workflow and less bottlenecks, which lead to better team productivity.

Small user stories help shorten the feedback loop

When user stories are smaller, they are completed faster, therefore providing the Product Owner and other stakeholders the opportunity to provide feedback more often. When the team receives feedback more often, they can be ensured that they are working on the right stories, which in turn, ensures that the correct product is being built.

Can user stories be too small?

Yes, definitely. I remember one team in particular that I was on where the size of stories was discussed in the sprint retrospective. The team all agreed that the stories needed to be smaller. The next retrospective, we were discussing that the stories were too small. So, even though it is beneficial to have small stories, beware of making them too small. For example, if you are changing the size and color of 5 headers on a page, it’s probably overkill to have 5 separate stories for that. The overhead of creating and moving the stickies or updating the tool is probably more work than actually updating the headers.

To sum it up, small user stories provide clear benefits and add more value than larger user stories. However, breaking stories down is not as easy as it sounds and the team needs to work together to find the right size. It takes team collaboration and it takes practice. But it’s worth it, so give it a shot with your next batch of user stories.