Stephen Hawking said we’re entering the age of complexity. What is complexity really? A complex system is a system that is un-ordered and un-predictable and can only be understood through feedback. A complicated system is ordered and structured and can be understood through analysis.
Let’s simplify. The electrical system of a car is complicated. With enough analysis and skill you can reverse engineer it and have predictable results in it’s output every time.
An organization is a complex adaptive system and cannot be reverse engineered or understood with analysis alone. Think of the last time you tried to change something in your organization and thought that some people were resisting the change. The change may have made perfect sense to you but you can’t predict how others will react and you can’t understand the system until you introduce the change and get feedback about whether or not it’s working.
Can measuring happiness help manage complexity and help organizations adapt faster to these rapidly changing times?
Gallup estimates that lost productivity due to dis-engaged employees costs the US economy $350 Billion annually. Three Hundred and Fifty Billion Dollars! I’d wager that dis-engaged employees are un-happy employees. If you hate your job do you really think you’re engaged and giving it your all every day? Are you miserable because the work sucks? Your boss is an idiot? The commute is killing you?
Crisp, a consulting firm based in Sweden, uses happiness index on a weekly basis to make sure people are happy. If people aren’t happy, they change something about how the organization works to keep people happy. This is possible because of the deep trust and respect they have with their employees.
InfoQ recently picked up one of my posts as well as other posts from various blogs about the impact of happiness in the workplace.
One of the practices of Management 3.0 is the use of Happiness Index or Noki Noki. Simply have your staff keep a piece of flipchart paper visible and have them draw a frowny face, mad face or happy face at the end of every day on the chart. At the end of the week, talk about what events made people feel happy, sad or mad.
Stephen Hawking said the 21st Century will be the century of complexity. Lean practices as pioneered by Toyota in the 50’s and beyond gave managers the tools and ability to manage complicated work. Over the years as Agile software development practices emerged, managers still used management by objectives and other manufacturing techniques and metaphors to manage how software teams deliver.
Software has proven to be much more complex than manufacturing. While complicated, manufacturing is ultimately a repeatable process that leads to predictability. With the increasing number of programming languages and techniques for delivering solutions to customers, Agile Management has been an over-looked aspect of software development.
Agile Management 3.0 changes that based on 6 new management views that borrow from complexity science, Demming’s profound system of knowledge, spiral dynamics and a whole host of theories and ideas designed to help people manage systems instead of people:
Energize People: Rewarding employees with carrots and punishing them with sticks simply doesn’t work in today’s complex social organizations. Performance reviews, while designed with good intent, are often de-motivating. Management 3.0 helps managers learn what really motivates people and why it’s necessary to treat different employees differently.
Empower Teams: Mastery. Autonomy. Purpose. Teams that excel have managers who know how to enable this and it’s a core practice of Management 3.0
Align Constraints: Self-organizing teams don’t simply happen by sticking people in a room together. Management 3.0 helps managers define system boundaries which helps push decisions down to the team enabling the people who are doing the work more autonomy.
Develop Competence: Sports teams practice. In today’s fast-paced world software delivery teams are often in ‘game mode’ constantly and don’t have the time to practice new skills. Management 3.0 helps managers enable slack time to help guide and build more effective teams.
Grow Structure: Often software delivery teams are hampered by the constraints around them such as incentives for testers to find defects which work against the incentive developers have to not produce defects. Management 3.0 helps managers put structures in place to optimize the whole value stream.
Improve Everything: Continuous Improvement is difficult to obtain but there are more modern practices like Lean Change that can enable it. Management 3.0 brings many ideas and methods not only from the software world but from the change management world to inspire a continuous improvement mindset.
Today’s organizations are complex adaptive systems and while we like to think software is a linear process that is repeatable, it isn’t. Great organizations understand how to enable kick-ass teams and the 6 views of Management 3.0 give managers, team leads and leaders the tools necessary to effectively manage software teams.
Changing the world is hard work. Why not start at the source? In schools. Myself and Andrew Annett have been conducting Lean Startup workshops for the University of Waterloo Enterprise Co-op (E Co-op) students, a program which is by the Conrad Business, Entrepreneurship and Technology Centre.
I was surprised to find out that Lean Startup, Agile and Lean practices aren’t part of the curriculum in many schools so I decided to do an experiment which raised the attention of my April 3 workshop to one of the entrepreneurs in residence. The rest is history.
The focus of this workshop is to introduce students to Lean Startup and give them an opportunity to build their MVP. All of the students have businesses ideas or have started their own business as part of the program. I don’t want to spoil the ideas but suffice to say I have a tremendous amount of faith in the future of our technology world given how unbelievably bright and energetic these kids are!
This is an interactive workshop. I yap for a about 20 or so minutes and then we break into groups and work on either a Business Model Canvas or get started on ideas for their first MVP including how to measure it. The feedback was overwhelmingly positive, check out this quick interview with a couple of the students.
Thanks to everyone who attended Silicon Halton’s first Lean Startup workshop at Club e-Spot! I was pleased to see one attendee found a customer at the session and earned a $500 commitment for her service. A service that she didn’t really know the direction of before the session started!
4 people brought ideas with them and after a quick presentation on mistakes I’ve made using Lean Startup in the past, we got started. Each group had a mentor from Lean Intuit and the objective of the sessions were to have either an MVP or a list of experiments they could get started with the next day. The feedback was overwhelmingly positive from the session, here are a few interviews I conducted after the session was finished. The great thing about this event was that people came in with an expectation to learn about Lean Startup and ended up getting real insights and next steps for their idea!
Sonya: She came to the session with an idea and by the end of the night had her idea refined and got a $500 commitment from a customer that very night!
Hans: Hans was dead in the water with his idea. He was struggling to find out who his customers were and how to get his idea to stick. The morning after the session he created his Lean Canvas and his first MVP!
Sebastian: He had a couple of ideas and wasn’t sure how to focus on next steps. Getting outside insights from other people at the session helped him let go of his personal bias towards his ideas.
If you are interested in this workshop, contact me!
Thank you to those who attended our Usability (UX) Testing and Prototyping session at Sheridan last night! Julie Buelow gave a fascinating and engaging presentation on usability testing which included some great examples from real-world scenarios and websites.
Here are my top 8 takeaways for me from the meetup.
Define your Purpose: What is the purpose of the site or product you are building? What problems will it solve? Avoid the temptation to make assumptions and get too far into details at this point.
Identify your Audience: Who are you trying to reach? What demographic? What age group? What cultural group? Once you have a purpose and have identified your audience, you can start to test images and messaging and website/app structure. The example used was a public health site for youths to find out about safe-sex. The site is for high-school students, don’t use messaging targeted at their parents.
Talk to Real Users! This goes without saying, bring in real users of your system and test your prototypes (ideally lo-fi). Provide them context, a safe environment and observe and write down their feedback. Talking to real users is the best way to validate and in-validate your assumptions. Contrary to your belief as a subject matter expert, you don’t know until you’ve tested your prototypes, imagery and messaging on real users of the system. The key about using lo-fi prototypes is users are less likely to critic the design and more likely to give you raw feedback about the usability. More on this later in this post!
Create a Safe Environment: It’s important to make your usability testers (again, they are REAL users) comfortable by explaining to them that you are testing your website or product and NOT them. They need not feel embarrassed if they can’t find what they are looking for. Make it clear and re-iterate that the users aren’t being tested, they are contributing valuable insights into making a better website or product.
Language and Imagery are Important: Industries like healthcare and finance use big words that can be meaningless to users. The example we used was public health. The subject matter experts wanted to use the medical term for diseases. The general population doesn’t understand what those words mean. Instead of using “Vector-Borne disease”, use “West Nile Virus”. That’s what people understand. Ditch the temptation to put animations and other flashy stuff on your site because changes are, users don’t want it.
Use Webstats to find trends: don’t use these stats as vanity metrics (IE: total visitors and view), analyze the navigation flow through the site. What are the most popular pages? WHY are they the most popular? Why isn’t what YOU thought the most important page more popular? Look at your stats before and after you make changes to see how user behaviour has changed.
Did UX tweeks solve a problem? Are users calling your helpdesk less because your site or product is easier to use? Find a valid business metric to help you make decisions and find out what’s working and what isn’t.
The 5 Second Test: Let a usability tester spend 5 seconds giving their first impression. They are not trying to find or accomplish something, you want their first raw impression. 10 years ago you had 10-12 seconds to make an impression on users, now it’s about 5 seconds. If users are confused they’re not likely to come back.
How Does UX Fit into Agile?
Well, that’s the million dollar question. From my experience, UX is often thought of as an ‘outside-the-development-team‘ activity and I’ve worked in organizations where UX is considered to be “hey, let Bob skin that when we’re done“. Mockups or prototypes are done in isolation and handed off to the team for implementation. Here’s an example Julie used. On a form to collect immunization data for kids, the parents were presented with a form so they can enter name, sex, health card number and other meta-data. If the ‘sex’ radio buttons weren’t checked, the popup error showed “Sex required“.
Works as designed.
Julie’s presentation and approach to UX IS what Agile is all about. Agile is about understanding your purpose and customers and building them a solution that solves their problem. Julie admitted to not knowing much about Agile and myself and Paul Carvalho told her to stop learning about Agile because the way her and her team works is what it’s all about! We would hate for ‘Agile’ to tarnish her user-centric approach and common sense!
3 Tips for Bridging the Gap Between UX and Agile Teams
Involve Product Owners and Stakeholders into the entire UX process: It’s easier (and cheaper) to change a mockup than software. Spend the extra time making sure you’re building the right thing first. This can be helpful if you have a pushy stakeholder who thinks they know it all. Bring them into a usability testing session using their idea and let them see if real users struggle with it. That can be an eye-opener.
Involve the whole team in the UX process: The team (programmers, testers, scrum master, product owner) will benefit greatly from the additional context. It will help team members understand the purpose of what’s being built and more than likely they will have ideas too.
Hire an UX Developer! I was surprised to hear that many of Julie’s clients don’t want UX testing because of the extra cost. You will pay for it later in helpdesk calls and rework.
After the presentation, Julie did a usability test on this website. I created this using WordPress and picked a new theme a couple of days ago. The feedback I got was great! Brutal, but great. Here’s the raw video of the test:
I got my money’s worth when Mike said right off the bat he didn’t notice the menu and didn’t know where to go. Sue also mentioned that the headers of the 3 boxes looked like buttons so she tried to click them. Many people echoed back they didn’t know what the site was for and that having ‘meetings, workshops and training’ was confusing.
This is the important part, your website or product is going to be near-and-dear to you. Let it go. Seriously, let it go. At first I was upset. Mike said he was looking for meetups and he clicked the blog menu item. My first reaction was “ok, seriously??? It’s RIGHT THERE, 3 BUTTONS OVER!“. The point is, he was looking for something and couldn’t find it. I have a pile of notes about changes I’m going to make to the site now.
I would like to thank Julie for her presentation, it was eye-opening for me and she was fantastic! Were you at the workshop? What are your thoughts?
Thanks to everyone who attended the meetup! We started off with an exercise to demonstrate why collaboration is more effective than documentation (and sub-sequent handoffs of said documentation). During the first part of the exercised that was document driven, 2 and half of 6 customers accepted the product. I say ‘half’ because one of the customer said “I dunno, well, kinda, yeah, I guess it’s ok“. During the second half where we demonstrated collaboration over written documentation, 5 of 6 customers accepted the product! Collaboration FTW!
We then moved onto visualization techniques for product discovery. We talked about using story-maps, videos and mind-maps for quickly setting context for your team and enabling a collaborative environment for your team to work in.
These are some of the tools and links to other articles based on our discussions.
JIRA w/Greenhopper: Great tool for managing work, Greenhopper plugin (which is now standard with JIRA) adds “Agile stuff” like task boards, burn-downs (release and sprints) and more.
Balsamiq: wireframing tool. Lets you create clickable PDF mockups to do full usability testing without writing any code.
Story Mapper: Plugin for Pivotal Tracker for creating story-maps
Other Links and Resources:
Agile Product Design: Jeff Patton created the concept of story-maps, his site has tons of information about story mapping, prototyping and more.
I was talking with a co-worker the other day and he was mentioning how he loved our weekly department standup meetings. A stand-up meeting is a quick 15 minute meeting that provides a forum for Agile teams to plan their day. It’s called a ‘stand-up’ because you stand-up during the meeting to keep it quick.
I wasn’t in much of a debating mood so I didn’t tell him that what we do is in no way shape or form a ‘stand-up’ meeting based on what a stand-up meeting is for an Agile team. Ours is a status meeting. Each department spits out metrics that could be replaced with $2 worth of sticky notes and at the end of the meeting we all go our separate ways. Personally I find them useless and the data spit out is gone from my brain about 10 seconds after the meeting is done. Here are some signs that you have a ‘status meeting’ and not a standup along with some tips for having a better actual standup meeting.
Signs You’re Doing a Status Meeting
team members report on they story that “they” are working on: The problem here can be lack of sustainable pace (taking too many stories), lack of a sprint goal or ignorance of what a standup is supposed to be
you use a token during the standup: Team members report on what they did yesterday, what they’ll do today and what impediments they have. New teams tend to talk over each other so Scrum Masters may introduce a talking token like a white-board marker, ball, bean-bag or what-have-you. If your team has been together more than a few sprints and you’re still doing this you really don’t get it. After a few sprints a team will realize the goal of the standup is to plan the day, not follow a token-rule.
you never report impediments: I’ve heard team members give an update like: “I’m working on story X, it’s been a few days and I can’t figure out how to do Y. Today I’ll keep working on it. I have no impediments.” Ok, seriously?
somebody is taking meeting notes: I don’t even want to touch this one.
It takes more than 15 minutes: keep it short, if you go over 15 minutes you’re getting into too much detail.
A manager runs the meeting: this is wrong on so many levels.
your team makes ‘chickens and pig’ jokes: The story goes: A chicken and a pig are talking about opening a restaurant and they want to call it “Ham ‘N Eggs”. The pig says “That’s great for you, you’d be involved and I’d be committed“. It’s supposed to mean that “pigs” are team members because they are on the hook for the sprint deliverable. “Chickens” aren’t allowed to participate. This is childish and making reference to it shows the signs of an immature team that really doesn’t get it.
These are a few signs you’re off track. Scrum is about self-organizing teams and a team that exhibits these symptoms has a whole bunch of deeper problems. Some of these problems can be organizational related as well, watch for them and use the retrospective as an opportunity to correct them.
Last weekend Lean Startup machine was in Toronto. The goal of the weekend is to take your idea and validate there is a market for it by getting customers to give up something valuable, typically money. The winning idea went to Team Hire Shark for their idea about how to help companies find the right employees for their company. Check out the full details about this on Epilogger.
Do you have an idea for a product or want to discover a more efficient way of designing your product? The Silicon Halton Agile/Lean P2P group is hosting a meeting on February 21 at 6.30pm on Rapid Product Design using Agile Techniques. In this interactive workshop you’ll learn about how to compress the time between your idea and getting validated feedback from your targeted audience. You’ll learn visualization techniques and various methods for brainstorming, planning and prototyping.