Daily Scrum

What is the Daily Scrum for?

The daily scrum / daily stand-up / daily huddle. Oh well.

The good questions are:
1. What have you done yesterday that contributes to reach the sprint goal?
2. What will you do today that contributes to reach the sprint goal?
3. Do you encounter any impediments/issues/problems that prevent you from reaching the sprint goal?

The habit of each person listing all the things he has done yesterday, and what he will do today is quite besides the point. The daily scrum is not a status meeting, it’s not a reporting meeting. In essence people should say what and how they’re progressing towards the sprint goal, and think and act as team how to plan their work together… for the next 24 hours. So yes, it’s a planning meeting, for the shortest iteration: the next 24 hours.

There are many “anti-patterns” regarding the daily scrum:
– Talking to the board, and not to the people
– No board at all
– Talking only to the scrum master
– Not expressing the progress of what your working on
– Having no sprint goals (so nothing to measure against)
– Talking too much, speaking about sprint goal – irrelevant stuff (for example discussing tasks in detail)
– Discussing problems and solutions in great detail > these should be taken offline, by preference the discussion continues in subgroups (with the relevant people), directly after the daily scrum (when the topic is still hot).

Lean UX cycle

Lean UX cycle

Lean UX = applying Lean and Lean Startup principles to User eXperience.

Remove waste from the UxD process

Too much too often product (software) design and development is document-driven. With the agile manifesto and principles in mind, we want to focus on creating great and valuable products (software) and releasing these early and often to get valuable end-user feedback, in order to improve our products (software) iteratively and incrementally.

Forget about the overload of UxD deliverables that are created to communicate “specifications” to “developers”. Re-consider and only create those deliverables that truly serve a purpose. We value “making” over “analysis“; we value “building” over “specification“. Lean helps us to focus on flow and to reduce non-value creation (waste).

What do I mean?

Useful deliverables (depending upon your context):

  • Branding and styleguide (by preference a living styleguide, to minimise maintenance effort)
  • Low-cost prototypes used in user testing
  • Low-cost sketches, mock-ups, designs, etc

Overhead deliverables:

  • Detailed User Interface specifications (for example including annotations of every screen)
  • Wireframes of every screen, every screen size
  • Visual designs of every screen
  • High-fidelity mockups (not reused in development)

Try to minimise the “upfront” creation of large UxD deliverables to be handed over to developers, instead rely on true cross-functional collaboration.

Cross-functional collaboration

True cross-functional collaboration (including designers, including UX people, including usability engineers, including developers, including product owners, including business stakeholders, marketeers, etc). True agile cross-functional collaboration is the foundation and the catalyst for collaboration and short development / release cycles. Agile re-focuses product (software) development on value creation and working products (software).

In every step of the cycle, and from the very beginning, the whole team is involved. The whole team approach aims to create a shared understanding with everyone, all the time. Knowledge, user feedback can be quickly spread and shared, and the team minimises the need for handovers (in any form: documents + interpretation, pass-through communication, re-discussions, etc).

Apply the scientific method

BUILD > MEASURE > LEARN

or

MAKE > CHECK > THINK

The scientific method exists for centuries and we are simply applying it to nowadays product (software) development.

"The Scientific Method as an Ongoing Process" by ArchonMagnus - Own work. Licensed under CC BY-SA 4.0 via Wikimedia Commons - https://commons.wikimedia.org/wiki/File:The_Scientific_Method_as_an_Ongoing_Process.svg

“The Scientific Method as an Ongoing Process” by ArchonMagnus – Own work. Licensed under CC BY-SA 4.0 via Wikimedia Commons – https://commons.wikimedia.org/wiki/File:The_Scientific_Method_as_an_Ongoing_Process.svg

In Lean Startup this is known as the build > measure > learn cycle. This is an on-going process, it obviously doesn’t stop with 1 iteration. We also call this make > check > think.

Lean UX cycle basic

Lean UX cycle basic

The only way to create products (software) which matter for your end-users, which mean a difference, which serve their needs is:

  • by first focusing on outcomes (objectives) and next on features (solutions)
  • by getting in touch with your end-users, observe and measure how they use your products
  • by focusing on creating valuable experiments to expose risks and uncertainty
  • by improving whatever you’re making based upon that feedback
  • by building upon collective knowledge and wisdom and let the whole team flourish in creating the best experience
  • by creating products iteratively and not only incrementally
  • by minimising the total time going through this process
  • by creating an environment of continuous learning

Learn more about Lean, Lean UX and product development with experiments in follow-up posts!

  • Techniques to bring UxD and development closer together, why collaboration matters.
  • The scientific method and product development with experiments
  • How to organise user testing
  • How to incorporate validated learnings

Resources

Lean UX book

Materials in this post are based upon readings on the topic of Lean UX.

Lean UX book by Jeff Gothelf.
Lean UX (Jeff Gothelf)

A few articles

The success of team work, quote by Henry Ford

Exploring team dynamics

Topic of this short talk: team / group dynamics. The point is that you need to be aware of any dynamics happening in your team / group!

Contents of the presentation:

Slide 1: Intro video (ants)

Nice illustration of actual teamwork 🙂

Slide 2: Teamwork

  • Teamwork is the corner stone of any successful undertaking.
  • Teamwork is an individual skill.
  • The purpose of this presentation is to make you aware of the importance of team dynamics.
  • We will look at some examples, and how we can explore team dynamics.

Slide 3: How does a high-performing team look like?

  • Diverse members
  • Diversity of viewpoints, opinions
  • Open and clear communication
  • Managing conflict
  • Clear objectives
  • Trust
  • Participative leadership
  • Positive atmosphere
  • Engagement

The list is long! It’s not so obvious to become a high-performing team.

Slide 4: Putting a group of people together does not make a team.

In case you didn’t know. Just putting people together and hoping “team” magic will appear, or self-organisation will occur; is most of the time wishful thinking. (I have witnessed this in projects …)

Slide 5: Model of group/team development: Tuckman (1965)

One of the basic models about team/group formation. Note the different phases of growing as a team are necessary to become “performing”.

Slide 6: Belbin team roles (1981)

9 team roles: an effective team has members that cover the 9 key roles in managing the team. (cf. Belbin website)

Slide 7: Communication inside the team is a key indicator of whether they are performing or not.

The quality of communication in the team will also directly affect the communication with the stakeholders! Do you want your team to communicate with stakeholders in this way?!

Slide 8: One bad apple can cause rot in the entire cart by altering the behaviour of everyone.

Yes, this is outcome of scientific research.

Examples of bad apples in a group: the passive-aggressive group eroder, the blunt/rude dominant, the controller, the slacker, the anti-establishment guy, the divide-and-conquer schemer, the arrogant fat head

Slide 9: Groupthink

Groupthink is a term coined by social psychologist Irving Janis (1972), occurs when a group makes faulty decisions because group pressures lead to a deterioration of “mental efficiency, reality testing, and moral judgment”.

Groups affected by groupthink ignore alternatives and tend to take irrational actions that dehumanise other groups. A group is especially vulnerable to groupthink when its members are similar in background, when the group is insulated from outside opinions, and when there are no clear rules for decision making.

Cf. https://en.wikipedia.org/wiki/Groupthink

Slide 10: How to explore team dynamics?

  • Listen to the way team members are communicating
  • Observe behaviours: can you recognise certain team roles? Who has an introvert personality, who’s extrovert?
  • Observe how conflict is managed

Slide 11: Don’t be a Scrum Zombie (Thanks to Henrik Kniberg)

Please don’t!

Slide 12: How to explore team dynamics?

I suggest for team building: a classic scrum.

Slide 13, 14, 15: How to explore team dynamics? Team drawer

A team building exercise.

Slide 16: Improv theatre exercises

There’s a book about improv for agile teams.

Slide 17: Quote by Henry Ford

“Coming together is a beginning, keeping together is progress, working together is success.”

Slide 18: Be aware of the dynamics in your team!

Lean UX cycle

Lean UX: What is Lean UX?

Lean UX is about apply lean principles to User eXperience.

Why?

There are 2 main observations:

Bad UX. Failed products.

Unfortunately, there are still too many (software) products and services built and released on the market, that do not fit the customers’ needs. This is a long lasting pain in software development. Nowadays thanks to modern web & mobile technologies, possibilities are endless. But than again there are still too many useless, badly designed, wrongly understood, misfit products with failed UX.

Search the web for “failed products” and you get a few examples.

Creation of software by writing documents.

The purpose of creating software is to serve the users’ need, to solve their problem, to automate their work, to meet their goal, to be convenient in use. Software is an end, not a goal. The experience has to be right, it must properly function, the experience should be neat and crisp.

Unfortunately, when creating user experiences, many product (software) development teams are organised in a way so that:

UX people “produce” the “UX” and create a document, a deliverable (“the UI/UX spec“). “The spec” is delivered to the developers who will make the wonderful UX real.

Documents do not solve users’ problems; software does.

With the agile manifesto in mind:

Working software over comprehensive documentation

We know and we owe it to ourselves to focus on delivering a working product, to collaborate and to work to the highest standards, and to minimise any unnecessary intermediates (such as “the spec“). So why do still so many teams (agile or non-agile) keep on focussing on “big UX design upfront”?

Applying Lean principles to product creation and UX will help us to focus on creating a right product fit, by creating value, and by minimizing any waste in the process. Likewise agile, likewise lean, Lean UX is a mindset, a process change and a way of thinking how to create the right product in the right way.

Lean?

The core idea is to maximize customer value while minimizing waste. Simply, lean means creating more value for customers with fewer resources.

A lean organization understands customer value and focuses its key processes to continuously increase it. The ultimate goal is to provide perfect value to the customer through a perfect value creation process that has zero waste.

What is Lean? (lean.org)

UX?

UX or User eXperience is about the user experience, but also the whole customer experience. It’s more than design aesthetics. It’s the result of the combination of design, interactions, architecture, technology, business goals, etc.

UX iceberg

UX iceberg

Source: UX iceberg;
http://arquiteturadeinformacao.com/wp-content/uploads/2012/03/ux_iceberg.png

Lean UX

Materials in this post are based upon readings on the topic of Lean UX.

Lean UX (Jeff Gothelf)

Lean UX (Jeff Gothelf)

Agile By Example 2015

Agile By Example 2015

Agile by Example (taking place in Warsaw, Poland) is a great conference. The 1st day there are workshops, the 2nd and 3rd day the conference takes place in a cinema!

Warsaw

Warsaw

Warsaw

Warsaw

Warsaw

Warsaw

Agile By Example 2015

Agile By Example 2015

ABE 15 in the cinema

ABE 15 in the cinema

Great presentations, on a huge screen and comfortable chairs to sit in. One could say that there’s a greater distance between the speaker and the audience, but for me the experience was superior 🙂 Moreover, the speakers were hanging around after their session, so you could go and speak with them, ask some questions.

The talks have been recorded and videos will be published on the Agile By Example YouTube channel

Day 1

Workshop on management 3.0 workout techniques (by Daniel Skowroński @_skowronski)

We’ve created our own personal map and played the moving motivators.

ABE 15 - Management 3.0

ABE 15 – Management 3.0

Day 2

Beyond Budgeting (by Bjarte Bogsnes @bbogsnes)

ABE15 - Beyond Budgetting

ABE15 – Beyond Budgetting

Evo Planning (by Niels Malotaux @nielsmx)

Niels talked about “evolutionary planning”

ABE 15 - Evo Planning

ABE 15 – Evo Planning

Make Impact Not Software (by Gojko Adzic @gojkoadzic)

Gojko presented a great talk. Gojko presents on high tempo, telling a story, nicely visualized and in-depth.

ABE 15 - Make Impact Not Software

ABE 15 – Make Impact Not Software

ABE 15 - Make Impact Not Software

ABE 15 – Make Impact Not Software

ABE 15 - Make Impact Not Software

ABE 15 – Make Impact Not Software

Be on a par during Sprint Retrospective (by Izabela Kowalik @izabela_kowalik)

Proposal on an alternative way to hold retrospective (instead of the usual Glad, Sad, Mad) FYI here’s a site about different retrospective formats.

ABE 15 - Be on a par during Sprint Retrospective

ABE 15 – Be on a par during Sprint Retrospective

Silent Sort Estimating (by Tomasz Wykowski, @twykowski)

Technique for estimating (alternative to planning poker)

ABE 15 - Silent Sort Estimating

ABE 15 – Silent Sort Estimating

ABE 15 - Silent Sort Estimating

ABE 15 – Silent Sort Estimating

My Lean Spectacles (by Tobbe Gyllebring, @drunkcod)

ABE 15 - My Lean Spectacles

ABE 15 – My Lean Spectacles

Grat talk by Tobbe. What I surely remember:

FAIL = “First Attempt In Learning”

Lean = LeaRn

Day 3

Limit WIP or DIE (by Jim Benson @ourfounder )

I had the pleasure to dine & wine with Jim Benson and some other great agile people. Jim Benson’s talk was spot on: too many organizations struggle with too much WIP (Work in Progress) and fail to see that this prevents them from moving on to “real” flow.

ABE 15 - Limit WIP or DIE

ABE 15 – Limit WIP or DIE

ABE 15 - Limit WIP or DIE

ABE 15 – Limit WIP or DIE

ABE 15 - Limit WIP or DIE

ABE 15 – Limit WIP or DIE

ABE 15 - Limit WIP or DIE

ABE 15 – Limit WIP or DIE

ABE 15 - Limit WIP or DIE

ABE 15 – Limit WIP or DIE

Examples how to move towards Zero Defects (by Niels Malotaux @nielsmx)

ABE 15 - Examples how to move towards Zero Defects

ABE 15 – Examples how to move towards Zero Defects

ABE 15 - Examples how to move towards Zero Defects

ABE 15 – Examples how to move towards Zero Defects

Strategy Deployment: The Secret Sauce for Enterprise Agility (by Karl Scotland @kjscotland)

ABE 15 - Strategy Deployment - The Secret Sauce for Enterprise Agility

ABE 15 – Strategy Deployment – The Secret Sauce for Enterprise Agility

ABE 15 - Strategy Deployment - The Secret Sauce for Enterprise Agility

ABE 15 – Strategy Deployment – The Secret Sauce for Enterprise Agility

ABE 15 - Strategy Deployment - The Secret Sauce for Enterprise Agility

ABE 15 – Strategy Deployment – The Secret Sauce for Enterprise Agility

ABE 15 - Strategy Deployment - The Secret Sauce for Enterprise Agility

ABE 15 – Strategy Deployment – The Secret Sauce for Enterprise Agility

ABE 15 - Strategy Deployment - The Secret Sauce for Enterprise Agility

ABE 15 – Strategy Deployment – The Secret Sauce for Enterprise Agility

No estimates: how you can predict the release date of your project without estimating (by Vasco Duarte)

Vasco published his book on #NoEstimates. Besides being a widely discussed topic (like on Twitter) with many people saying nonsense; Vasco’s talk was both amusing and enlightening. His book is on my reading list. FYI also Yves (Hanoulle) @YvesHanoulle facilitated a discussion on #NoEstimates topic at ACB (Agile Consortium Belgium)

ABE 15 - NoEstimates

ABE 15 – NoEstimates

ABE 15 - NoEstimates

ABE 15 – NoEstimates

ABE 15 - NoEstimates

ABE 15 – NoEstimates

ABE 15 - NoEstimates

ABE 15 – NoEstimates

Product development is an experiment (by Jim Benson)

One of my favorite talks. I am a huge advocate of approach any product/service/software development as an experiment (hence my interest in Lean UX, Lean Startup, Discovery Kanban). Build / measure / learn is the basic cycle for any product development. Moreover Jim explained that creative product development is a team sport: a collaborative approach.

ABE 15 - Product development is an experiment

ABE 15 – Product development is an experiment

ABE 15 - Product development is an experiment

ABE 15 – Product development is an experiment

Taking Back Agile (by Tim Ottinger @tottinge)

Great closing by Tim about going back to the root values and principles of agile.

ABE 15 - Taking back Agile

ABE 15 – Taking back Agile

Panel discussions and possibilities to talk with the experts were also happening.

I had the opportunity to wine & dine with great people:

ABE 15 - dinner

ABE 15 – dinner

Agile by Example, I’ll return.

ABE 15 - closing

ABE 15 – closing

Real sprints

True cross-functional product development

Cross-functional” collaboration in (agile) product development means that the whole (complete) product “development” team is participating. Scrum talks about a “development” team, without distinction of role. As such, “developer” means any competence or skill required to create the product or service, not limited to “programming” (writing code).

Lean UX heavily promotes the whole product development team participating during the complete product development cycle, from the very beginning. The whole team approach aims to create a shared understanding with everyone (all team roles) from the beginning and to minimize any waste originating from working in sub-teams or silos (hand-overs, intermediate deliverables, re-discussing the same topic with people who didn’t participate, etc).

Shared understanding

Shared understanding

True agile teams (feature teams) are product-oriented and are able to implement product features end to end, creating pieces of value with every item done. Collaboration with all team members is a great source of creativity, new ideas and innovation. This kind of cross-functional collaboration is demanding: people are expected to think outside their box, to participate in work outside their main domain, and to help to create that necessary shared understanding to be able to deliver value within an iteration.

Teams working in a phased approach (the so-called staggered sprints) face a number of worries – this should not be accepted as common, and such teams should strive for a better way of working. A phased approach is basically some work done in a sprint before the “development” sprint (or even worse, acceptance or testing after the”development” sprint).

Staggered sprints

Staggered sprints

The challenges with this phased approach are:

  • Sprints become out of sync
  • Iteration without agility
  • Lack of ownership amongst the developers
  • Groupthink
  • Waste (hand-overs, intermediate deliverables, etc)

The (single) (true) Scrum team approach has numerous benefits:

  • Understanding of concepts and users’ needs amongst all team members
  • Improved time to deliver (precondition is to deliver chunks of value you are able to implement within a sprint)
  • Less re-work, less waste
  • Improved definition of done
  • Sense of ownership amongst all team members

And so, we urge you to re-consider any large upfront work (before “construction”), and try to create shared understandings with the whole team. That shared understanding will lead to willingness to truly collaborate together within the same sprint. In the Lean UX approach you foresee a regular cadence of user tests. The aim is to create a “test everything” culture: we test what’s available and given the users’ feedback, we improve (we iterate).

Real sprints

Real sprints

Sources: