October 21, 2015July 25, 2017 by Frederik

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

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

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.

A few articles

The success of team work, quote by Henry Ford

October 19, 2015July 25, 2017 by Frederik

Exploring team dynamics

communication
abe15, team

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!

Agile by example 2015: lightning talk – exploring team dynamics from Frederik Vannieuwenhuyse

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!

October 18, 2015July 25, 2017 by Frederik

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

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)

October 12, 2015February 9, 2022 by Frederik

Agile By Example 2015

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

There are great presentations on a giant 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 channel.

Day 1

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

We’ve created our 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 Budgeting

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

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 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

My Lean Spectacles (by Tobbe Gyllebring, @drunkcod)

ABE 15 - My Lean Spectacles — ABE 15 – My Lean Spectacles

Great 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

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

ABE 15 - Examples how to move towards Zero Defects — ABE 15 – Examples of 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

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 amusing and enlightening. His book is on my reading list. FYI also Yves (Hanoulle) @YvesHanoulle facilitated a discussion on the #NoEstimates topic at ACB (Agile Consortium Belgium)

ABE 15 - NoEstimates — ABE 15 – NoEstimates

Product development is an experiment (by Jim Benson)

It’s one of my favourite talks. I am a massive advocate of approaching 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

Taking Back Agile (by Tim Ottinger @tottinge)

Great closing by Tim about going back to agile’s root values and principles.

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:

Agile by Example, I’ll return.

October 8, 2015February 4, 2022 by Frederik

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 entire team approach aims to create a shared understanding with everyone (all team roles) from the start 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.).

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

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

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) (proper) 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 extensive upfront work (before “construction”) and try to create shared understandings with the whole team. That shared understanding will lead to a willingness to collaborate within the same sprint truly. You foresee a regular cadence of user tests in the Lean UX approach. The aim is to create a “test everything” culture: we test what’s available, and given the users’ feedback, we improve (we iterate).

Sources:

value first!

Month / October 2015