Any information in the world falls into one of the 2 categories: it requires some action on our part, or it wants to be consumed (or browsed). The job of a UX designer or an infoviz/dataviz specialist, then, is to create UIs or pages with one of these goals in mind. If we want to subtly nudge users to browsing more pages in a passive mode, the design logic needs to be built just for that. If we want to help users act and save their time, rather than make them hang out on a web page, then the page layout or user interface has to take that into account. I will show the difference between these two kinds of logic based on the list and grid infoviz patterns from a news hub and from a project management tool.
It’s quite common nowadays to display news as a grid of tagline+image sets, maybe with a mouseover text. Here’s one such grid:
If we think about it, this image+headline+mouseover layout is used with one major goal: engage users. Make them spend more time browsing the news, move mouse over images, check a few headlines, click on an image. Once a mouseover text is displayed, it’s an easy-lazy thing to get to the full view of the news, with advertisements, videos and social comments. The grid layout, thus, appears to eat more of users’s time, luring them with this ease to click and to browse. In general, if we lay this whole “engagement” thing aside, reading news is a passive online activity, and it can be completed rather quickly. So, if someone wants to scan the news, rather than get stuck in them, they wouldn’t want to hover mouse over those pieces, checking for the clues. The grid layout in the news appears to be more “engaging”, as they call it, but it loses in terms of time spent vs. value gained. I mean, what if I don’t have time to move mouse over those snapshots to find out what’s behind a headline? Busy readers will likely want to just scan the news and headlines. They don’t even need those large image thumbnails. That’s why a list layout scores higher on the time spent/value gained scale. Check this out:
This layout allows to scan many headlines+summaries in one look. Readers are able to decide faster, if they want to click on some news or not, without mouseovers. Apparently, I would want to read more about the cleanup from storms, which left three dead, and I don’t have to hover mouse over an image, as in a kid’s game, to find out what the cleanup from storms entails. That’s why I like the list layout better: it is more respectful of my time. I must give credit to the UX designers of this news portal, though. They have provided users with an option to choose between a list and a grid.
That was the case with passive browsing. A few “active” things available to users on a news web-site would be clicking on an ad (the more time they spent there, the more likely they are to do that), posting a comment and/or sharing news in social networks. That’s the logic behind the grid design in case you were wondering why such a draining layout — that’s how it looks to me — should ever be used in the news. Another handy example of grid slowing us down is… our desktop. Often I just save stuff to my desktop, files, snips or images, and when I want to find something, it takes more time and effort to move eyes between thumbs, as compared to using a list or search.
Let’s now consider the logic behind the list and grid/board layouts in a project management tool. The UI of such a tool must encourage users to spend time productively. It might seem a stretched parallel, but in some ways board/grid is less efficient for project management as well. Lists will work better when it gets to managing bugs, for example:
If someone in charge, a QA manager, or anyone else, will want to create a living display of bugs, tailored for hands-on work, it would be such a list. Apart from the compact layout, the list has inline edit for most of the fields, and it’s like with processing fish: bug details can be updated faster than in a grid view. Besides, the very columns in this list are customizable; one can choose which column they want to see and which not. Now, what if this person in charge were to work with bugs displayed as a grid? Check this out:
As with the news portal grid, one has to move mouse over bugs for more details, e.g. to check on a bug’s severity. This grid layout would be a plus if I had time to leisurely contemplate which card might mean what, but if I want to change a bug’s status, assign people, or update tags, I need to dive further in *sigh*, click on the bug card and work there. The grid layout does not allow for quick scanning of the bugs and quick editing/updating. But it would be optimal for changing states as they do on a Kanban board. Thankfully, this project management tool allows users to switch between views when they want to do whatever they want :)
I hope these examples helped reveal some logic behind designing information layouts for various purposes.
Here's my research on the topic of creativity.
Predicting Creativity in the Wild-- a research paper on the use of sociometric monitoring of teams by Sociometric Solutions.
Actor John Cleese talks about creativity. It's about the open mindset of play.
Play is More than Just Fun - Stuart Brown; TED Talk
Stuart Brown has studied play in animals and humans and argues that it is a natural tool used for creative problem solving.
Play by Stuart Brown"We've all seen the happiness on the face of a child while playing in the school yard. Or the blissful abandon of a golden retriever racing across a lawn. This is the joy of play. By definition, play is purposeless, all-consuming, and fun. But as Dr. Stuart Brown illustrates, play is anything but trivial. It is a biological drive as integral to our health as sleep or nutrition. We are designed by nature to flourish through play."
"Dr. Brown has spent his career studying animal behavior and conducting more than six- thousand "play histories" of humans from all walks of life-from serial murderers to Nobel Prize winners. Backed by the latest research, Play (20,000 copies in print) explains why play is essential to our social skills, adaptability, intelligence, creativity, ability to problem solve and more. Particularly in tough times, we need to play more than ever, as it's the very means by which we prepare for the unexpected, search out new solutions, and remain optimistic. A fascinating blend of cutting-edge neuroscience, biology, psychology, social science, and inspiring human stories of the transformative power of play, this book proves why play just might be the most important work we can ever do."
Dr. Brown's 2008 three part PBS series on Play:
PROMISE OF PLAY, Part 1: The Mother of Invention
PROMISE OF PLAY, Part Two: A World of Your Own PROMISE OF PLAY, Part 3: The Heart of the Matter
Why games are an integral part of learning -- from the Institute of Play.
…if you are not defining your tests at the acceptance level before you are writing your code you are creating waste.
- Testing in Agile Projects: Familiarity Breeds Consent http://t.co/BkkdVSUmxs
- Organisation Antipattern: Release Testing http://t.co/Jy2mYp0goA
- 5 principles on quality and testing in the Agile context – by Jason Yip http://t.co/IRdFVWvwpO
- I’ve Had It With Defects « by Developsense Blog http://t.co/DeJ3yKIMBO
- Testing Quadrants As A Communication Tool | by Flow of Testing http://bit.ly/1j7Gig7
I don’t claim these articles to be the best on this subject, but I have enjoyed reading them and they have made my knowledge grow. I recommend you to have a look if you are interested in the subject. Happy reading!
Follow me on twitter @hlarsson for more links on a daily basis. You may also subscribe to weekly newsletter of my links. Thanks to writers of these articles and Kirill Klimov for collecting the agile quotes: http://agilequote.info/. Please follow @agilequote for more quotes.
WIKISPEED first designs a wrapper, usually a plate of aluminum with pre-defined bolt patterns, around the third party supplied part to create a known “interface” that won’t change, even if that third party part changes. You might see how this is enforced by principle 2: Object-Oriented, Modular Architecture and 4: Contract-First Design, and then sped up by principle 6: Agile Hardware Design Patterns.
Once each third party part is wrapped in a known interface, you can iterate between suppliers and in-house prototypes or volume parts at very low cost. The only marginal cost is that of changing the wrapper itself.
Then, to expedite suppliers, ask them to deliver a certain set of performance characteristics as opposed to an engineering specification. "Do you have a transmission suitable for 100hp motor?", not "Here is our design for a transmission, can you build it?" Why should you wait months for a supplier to build a device to your specifications when they have a device that will satisfy your needs already in the catalog or in stock?
Many engineers are quick to design their own solution, which works to the team’s advantage when the design team is also the volume manufacturing team. But in cases where some production is outsourced, sending a list of values and tests to the outsourced vendor and not sending an engineering specification gives the supplier the most room to innovate. This allows the vendor to do what they do best, that part, which is why you are partnering with them in the first place. Team WIKISPEED finds they get higher quality parts faster, often from within the vendor’s existing stock.
The 10 Principles of Extreme Manufacturing
I wonder if the problem is that management feels that they can't do anything about infrastructure at one of the largest telecommunication companies in the universe. Perhaps they believe that the cobbler's kids should have no shoes - that is is just the way of the world.
I frequently wonder if this program was a client of the company would they cancel their service for the networking products and seek an alternative supplier. I wonder if that would be an option for this program. I wonder if this is a case of having to eat your own dog food - imposed by some evil VP to make the teams understand just how bad the customers have it using our services and administering them using the system we have provided them - but then I realize - no that would take real organizational ability and if it could be used for evil - then surely it would be as easy to use that super power to organize for good. And since I can feel little organization, I assume there is no super power in existence.
So perhaps one step in the direction of making this problem understood would be to calculate the cost of the frequent network down times and make this cost visible. I've done this before with other such impediments - with varying levels of success.
I just saw this article:
How Much Does Network Downtime REALLY Cost Your Business? [Shocking]It contains a link to a calculator - makes it easy... try it - you might like it.
What would you do? Please leave me a comment with suggestions.
I recently completed a blog on PMs transitioning to a ScrumMaster role. I was inspired to put together a quick blog post for new ScrumMasters after reading a question that was posted to social media. The poster basically wanted to know how to drive the team without them reporting to him/her or having “control” over them. When I first read this I was perturbed but quickly thought to myself this person could be new to Agile and Scrum. I’ll refer back to my definition of a ScrumMaster, a servant leader who is an Agile champion for your team. I didn’t say management leader or controller or mother of dragons.
The ScrumMaster role is very challenging role and it takes some self control for people coming from a different role such as a PM or a lead from the team. I am not a fan of “working” ScrumMasters, meaning they are also coders or leads. They need to resist the urge to roll up their sleeves and dive in. A good example of this, I was working on a Legos4Scrum (By Alexey Krivitsky) exercise acting as ScrumMaster. Legos4Scrum is a cool way to introduce Scrum during an Agile bootcamp. You basically have teams working with sprints building items for a city while working with a product owner for vision of the city. All the other teams had working ScrumMasters meaning they were diving in helping to build items such as schools and hotels for the city. I was not building anything, instead I was separating the bricks, breaking bricks apart, sorting into colors etcetera making it easier for the team to build. Can you guess which team achieved a higher velocity? The team with a ScrumMaster who was constantly making the team’s job easier. I was also working with product owner with any questions the team had as they were building. I tracked down the product owner if need be, not the team member working. Do whatever you can to keep impediments down and efficiency high!
The servant leader side of the role is rewarding but being an Agile champion is crucial. If you are new to the role start to soak up as much knowledge as you can. At the end of the day you serve as the Agile coach for the team. You should know the ceremonies and fun ways to facilitate them. I highly recommend joining groups out there in internet land. If you have a local Agile group join it, attend the meetings and share your experiences. You will never stop learning. Your knowledge and ways to handle situations builds trust with the team.
Another piece of advice I have is to provide a fun environment for your team. Anything you can do to achieve this whether it is adding some cool posters or getting that energy drink fridge installed. Try coming up with fun ways to do the standups and retrospectives. If your team has the personality for it a prank doesn’t hurt from time to time. Now remember don’t rewire the power switch on a PC to a remote power switch unless they can take a joke. That was one of my favorite pranks I’ve ever been apart of. Soft dart guns can also be very interesting on Friday afternoon.
I have only scratched the surface, this is a topic I could type for days on since I am very passionate about it. That being said if you are a ScumMaster and have some tips please comment for those new ScrumMasters out there!
For those who did not hear, the Axosoft Bug Tracker is currently available for just $1/year for your entire team. It’s hands down the best deal you’ll find for a hosted solution and can still manage your bugs, workflows and team members great.
Now for some teams, our issue tracker will do the trick just fine. However, having awesome bug tracking software is only as good as your ability to find and report bugs. Why not offload that to your customers using the Customer Portal or have their emails become tickets you can track? Axosoft HelpDesk can do all these things. If you’re new to Axosoft HelpDesk, then check out this previous blog post to learn more.
If you’ve been using Axosoft Bug Tracker, you probably have a few questions about synergy with our other modules. To help you get an idea of the transition, here are some frequently asked questions:
What happens to my number of users when I upgrade to Axosoft HelpDesk?
The system automatically looks at how many active users you have on the Axosoft Bug Tracker. This becomes your new user count. But do you have users who only log and monitor bugs or incidents? If that’s the case, then they can submit and view items via the Customer Portal. All Axosoft HelpDesk hosted accounts get an unlimited number of Customer Portal users for free.
So for example, I initially had 100 users on the Axosoft Bug Tracker. However, 75 of those users only need to submit bugs or tickets. If that’s the case then those 75 users can become 75 Customer Portal users. You get unlimited Customer Portal users for free with Axosoft HelpDesk. That means I only need to pay for 25 users of Axosoft HelpDesk and Axosoft Bug Tracker while keeping access to ticketing for everyone else; great way to save money right?
Will I keep all my information when I upgrade?
Yep. Your defect backlog (along with all your other data) is preserved and unified with whatever combination of modules you decide to use.
What if I don’t want to show all my items to all my customers?
You don’t have to show anyone everything or anything. You have complete control of what is available for Customer Portal users to view thanks to Portal Security Roles.
With Axosoft HelpDesk can my customers report defects and incidents?
With the Customer Portal in Axosoft HelpDesk customer contacts can directly add items to your project. Axosoft HelpDesk also automatically converts emails into tickets, so customers can email inquires as well. More details can be found in a previous blog post here.
Does email ticketing and Customer Portal support any item types?
Yes! Whether you’re working with feature requests, incidents, bugs, wiki pages or your own custom items, the email-to-ticket automation and customer portal will work for all.
How much is Axosoft HelpDesk?
Axosoft HelpDesk is available for $7/user per month (same for Axosoft Wiki). Axosoft Scrum is available for $10/user per month. You can choose any assortment of modules and each user license will have access to all modules (though that can be limited by security roles). You also get Axosoft Bug Tracker for free with either Axosoft HelpDesk or Axosoft Scrum.
Can I have X number of users on bug tracker and Y number of users on HelpDesk?
Sorry, no. Our user licenses contain all the modules you subscribe to. It’s how we’ve chosen to design the product to maximize the synergy between our four modules.
Speaking of the other modules, of course there’s also Axosoft Scrum and Axosoft Wiki to consider adding to your system. Axosoft Scrum in particular does a fantastic job providing project visibility with its awesome burndowns, the Daily Scrum, and more.
If you have more questions about upgrading, then feel free to shoot us an email at email@example.com. For those of you fond of speaking directly with a human being, you can set up a free 1-1 session to hammer out these queries.
When multiple teams work on the same module, they each own a sub-module, which will require another finer pass of Contract-First Design to create interfaces for sub-modules before those teams can be created. For example, within the engine module there is the fuel system module, the engine electronics module, the exhaust system module. Each module has an interface that loosely couples it the other modules and clear tests of their value and technical excellence.
Creating TeamsApplied at WIKISPEED, the first design decision is the fundamental architecture of the product being created, in their case a car. What are the main modules, e.g. engine, body, drive train, cockpit, etc., and what are the interfaces between them? Once the modules have been identified and the contacts between them created (see XM Principle 4: Contract-First Design), sub-teams can be created on each side of an interface to develop that module.
If capacity allows and velocity and quality metrics indicate adding more teams per module will improve velocity and quality, then multiple teams can work in parallel per module.
Each team owns their own integration and tests, no team is “done” with an increment of their module until all tests pass, including tests that it complies with their module’s interface and no additional connections have been introduced.
Team CoordinationIn XM Scrum of Scrums, teams consist of 4 to 5 people, including a Product Owner and Scrum Master. Each product owner is responsible for pulling stories from the Portfolio Product Backlog (or simply "Backlog"), and getting clarity when their team needs it on the customer visible value and Net Present Value each story is intended to deliver.
This clarity comes from the Chief Product Owner (CPO) who sequences and refines the Portfolio Product Backlog continuously. The CPO is not a senior role in pay or experience, but is simply the person available enough to keep backlog ready for the teams, answer questions, and have the most clear understanding of the customer visible value the Portfolio Product Backlog is aiming to produce. Ideally, the CPO is the customer, and the one paying for the product or service the backlog is aiming to produce.
On each team, each Scrum Master is responsible for accelerating the velocity of the team, i.e. the amount of work sustainably delivered each sprint. Sustainible implies that the teams are happy and that all work completed satisfies the quality metric called the Definition of Done. Scrum Masters have an additional job here, too: they collaborate with the Scrum Masters of other teams to negotiate the shared resources like space, tools, and modules, across teams.
In this way, a team of 5 has clear expectations for themselves on how to resolve the most common types of impediments: lack of clarity is handled ASAP by the product owner, lack of backlog is handled ASAP by the product owner, lack of visibility into team delivery trend/quality/happiness is handled as a matter of course each week by the Scrum Master, and resource constraints and coordination are handled ASAP by the Scrum Master."
Next: XM Principle 10: Partner Patterns
The 10 Principles of Extreme Manufacturing
In einem Training, an dem ich letztens teilnahm, kam unter den Entwickler wieder ein Mal die Diskussion auf, dass es doch gar keine guten Entwickler gäbe und es so schwer sei, neue Mitarbeiter zu finden. Die Teilnehmer, eine Handvoll jahrelang in der Softwareentwicklung erfahrener Menschen, waren alle der Meinung, sie kriegen keine guten Leute, die Entwickler von heute wären alle nicht brauchbar.
Nach regem Kopfnicken und Zustimmung fragte doch tatsächlich einer der Anwesenden, was denn wohl die Gründe dafür seien. Diese Frage warf natürlich wiederum eine andere auf, nämlich: „Wer ist denn ein guter Entwickler bzw. welche Kriterien erfüllt dieser?“ Da es ein Training zum Thema Selbstorganisation war, haben wir uns einfach einige der Anforderungen an die jungen Bewerber genauer angesehen.
- Zunächst möge der Junior Entwickler genug Erfahrung mitbringen. Wie soll denn der Junior Entwickler Erfahrung sammeln, wenn alle nach Junior Entwicklern mit Erfahrung suchen? Nun gut, nach diesem Einwurf erbarmte sich einer der Teilnehmer und meinte : “Ja, man kann den sicher auch einarbeiten, ist ja noch kein Meister vom Himmel gefallen“. Puhh Glück gehabt, unser Bewerber hat unsere 1. Anforderung mit Ach und Krach geschafft.
- Der Entwickler sollte mit mehreren Tools umgehen können (es wurden so viele aufgezählt, dass der Platz auf dieser Seite dafür nicht ausreichen würde). Okay, einer kann ja nicht alles wissen, da waren wir uns alle einig. Aber zumindest die gängigsten Tools sollte der Entwickler im Schlaf beherrschen. Damit war auch der Großteil einverstanden. Vor allem sollte sich der Bewerber nur bewerben, wenn er tatsächlich die im Inserat angegebenen Tools auch beherrscht. Auch bei diesem Einwand wurde rege mit den Köpfen genickt.
- Der Entwickler möge sich seine benötigten Informationen selbst erarbeiten. In diesem Punkt gingen wieder die Meinungen auseinander. Die einen bestärkten mit Kopfnicken, während die anderen meinten, eine gute Einarbeitung seitens eines Seniors wäre unumgänglich. Bei diesem Punkt wurde sehr schnell das Thema Wissenstransfer angesprochen und auch die Tatsache, dass Senior Entwickler ungern ihr Wissen teilen. Aber auch bei diesem Punkt waren wir uns größtenteils einig. Ein neuer Junior Entwickler könnte genau diesem Problem entgegenwirken. Wir würden einen Senior Entwickler aus dem Team zu den Bewerbungsgesprächen dazuholen, damit er auch mitbestimmen könnte, wer eingestellt wird. Da auch er derjenige ist, der den neuen Mitarbeiter einarbeiten wird.
- Die Arbeit mit agilen Methoden wie Scrum, Kanban oder ähnlichem sollte für den Junior Entwickler selbstverständlich sein. Hier waren wir uns natürlich alle einig. Ein kompetenter Mitarbeiter, der selbstverantwortlich und selbstorganisiert arbeiten kann. Der cross-funktional arbeitet und über ein agiles Mindset verfügt. Oh ja, unser Herz ging auf bei diesem Punkt, und wir nannten noch viele weitere Punkte. Doch dann sagte einer: „Aber genau das ist der Grund, warum wir keine guten Entwickler finden.“
Was sollte das heißen? Wir waren alle doch recht verwirrt nach diesem Einwand.
In einem agilen Umfeld sind Soft Skills gefragt. Wir erwarten uns von den Entwicklern, dass sie kommunizieren, sich mitteilen, diskutieren und Entscheidungen treffen. Doch viele Entwickler werden Entwickler, weil sie sich nicht austauschen möchten und sonst kein Interesse an Kommunikation haben. Hinzu kommt, dass sie gerne Vorgaben haben, nämlich genaue Vorgaben. Diese Vorgaben nehmen sie, gehen in ihre Kammer und coden, bis sie alles abgearbeitet haben. Doch in einem agilen Umfeld planen wir iterativ, wir lernen dazu und verbessern uns immer wieder. Diese Entwickler tun sich sehr schwer mit dieser Art des Arbeitens.
Er glaubte tatsächlich, dass die fehlenden Soft Skills, die im agilen Umfeld erwartet werden, bei vielen Entwicklern nicht vorhanden wären, und dass dies der Grund dafür wäre, warum sich so schwer gute Entwickler finden ließen.
Und auf diese Ausführung hin gab es erneut reges Kopfnicken.
Success in software development business depends on an intricate fusion of optimized individual performances, be it for a C-level executive, or for a junior software developer, QA engineer or UX designer. Naturally, stakeholders want to drive business results to the optimum, using the leverages they can control, as they are looking for the ways to foster productivity of teams and individuals. In the end, it’s people who take decisions, come up with creative ideas and make working software. That’s why it’s so important to design a harmonious workspace that helps people feel good and deliver their best work. Enough has been said on how stressful environments strangle performance. A stressful environment, the way I see it, covers not only work, but lifestyle-related stresses, such as tedious commutes, being a parent to a newborn or overspending energy on a pursuit unrelated to work. Employers pretty much have no control over such things. A sensible employer will surely be aware of the impact they make on productivity, but these are life choices that people make, when it goes about babies and hobbies; it’s a matter of personal responsibility. Commutes can be controlled, partially, either by setting up an office in a favorable location with decent standards of living and reasonable population density, or by allowing remote work. What stakeholders can control completely is workspace. Rather than brooding over utopian surroundings, it makes sense to focus on the things that can be improved in your office.
That’s exactly what we do in our company, Targetprocess. We are in product development, and this implies that enhanced creativity and optimized individual performance are essential for the company’s success. In this business the price is too high if people are coming up with faulty solutions, on all levels. We simply cannot afford being downtrodden by a dull office environment.
A well-thought-out workspace can help a lot with these 4 things (or activities):#1. Informal exchanges
Very often, if not always, discussions on work-related issues occur anywhere but at a scheduled meeting. Such conversations can bring along some good ideas, from our experience. That’s why Targetprocess office has been specifically designed to encourage these informal exchanges. The office is made up of 3 round towers, and we have a lounge dining area in one of the towers, the Green one, where we carry free buffet lunches. There’s also an espresso machine with a counter, and this lunch space has snacks and supplies. This environment encourages people to talk and share ideas. Here’s a map view of our Green tower (we also have the Blue tower, and the Orange tower, the space takes about 11,000 sq feet in total):
The other two towers have coffee counters in the center, with bar stools and a cooler/heater nearby. Everyone is welcome to stop by, sit down and discuss something.
Another thing that we have in place to facilitate informal exchanges is a no-cubicle setup. Some of us had previously worked at companies with huge open spaces, which would be another extreme. Of course, people can talk freely when they sit in one large room, but the noise and distractions are horrible. So, we’ve arranged something in the middle and remodeled the original space in the towers as “slices of a pie”. Check the snapshot of the Blue tower:
These pie-slice rooms hold comfortable workspace for our feature teams. Each feature team is cross-functional, and includes software developers as well as QA engineers. They usually develop one piece of our product’s functionality. This workspace arrangement is more favorable for our development process than a maze of 50 cubicles in one open-space, looks like. And, of course, it fosters informal exchanges in feature teams.#2. Focused solo work
This kind of work can also be facilitated by office space. We have silent rooms, with a lounge chair or a couch, available to anyone who needs some time alone. One of these rooms is located in our office library. A UX designer, or a software developer, or a company stakeholder, or anybody else can walk in to the library (we have 300+ books and counting), pick a book from a shelf, flip through the pages, sit down in an armchair nearby and get some insight. Actually, a library is not only a part of an office space. It is a part of our continuous learning culture, which is mega-important to us as a software product company. Here’s a picture of some bookshelves in the library:
We believe in the power of all things visual. Nothing facilitates creative thinking and problem-solving more than having a problem sketched, visualized, diagrammed and dissected. Also, nothing can give a work status report faster than a crisp visual dashboard. That’s why our office sometimes reminds a school with many classrooms. We have whiteboards in every pie-slice room, and we’ve also used IdeaPaint to turn some of the walls into the renewable sheets for jotting down ideas, software architecture maps and what not. That’s how we visualized our production roadmap on an IdeaPaint wall a few years ago:
A large digital screen is another tool that helps a lot with visualizations. Just one example, that’s how we feed the status of our production builds to a screen:
This whole visualization philosophy is very strong with us, and since our product is a visual management tool, we have many screens with boards in the office.
These are the small things that do not directly contribute to productivity, but help brighten up the environment and make it happiness-oriented. Imagine, after a dull commute in a rainy day, or after a night of bad sleep you walk in to your office… and this charming cat greets you :)
This cat is a very influential guy, by the way. We use it as a token to identify who is in charge of automated test runs. The cat obviously feels some affinity with deer (this picture was taken at Christmas time).
It somehow happens that our employees care about the space around them. Such small things do not appear in the office by an executive rule. People use their own creativity to make their workspace vibrant. Take a look at this custom artistic installation at a QA engineer’s desk:
I believe each and every office can come up with things like that. Such DIY craftworks create a cozy environment at work, helping people feel relaxed rather than stressed out. When everyone is focused and still relaxed, that’s when the real good work happens.
There’s yet another dimension to office environments. Workspace can be improved not only with furniture, or artefacts, but emotionally. Harmonious emotional spaces facilitate improved individual and group performance as much as harmonious room spaces, if not more. But this would be a subject for another article.
I recently taught my first Scrum workshop in a while, after a number of years of doing other work. The team was excited and ready to go. The next day, they held a daily standup in the traditional style. Each person answered the three questions:
“What did I do yesterday?”
“What will I do today?”
“What’s slowing me down?”
But since they were sitting together, it really felt forced. They had all worked together they day before, and so the readouts of “what I did yesterday” were pretty useless. At the same time, “what am I committing to do today” was something they needed to collaborate on -- not something they could each read out independently.
At the time, I reminded them that this wasn’t meant to be a status meeting -- it was a time for them to coordinate, and they discussed a little bit more amongst themselves. The three questions, meant to be a starting point, were a distraction from what they actually needed to talk about.
Not too long ago, I was at an event where Jim Benson talked about his mission to end the question, “What are you doing?” in the workplace. If work is being made visible through some kind of system or board, the answer should be obvious. You don’t need people to read out on this.
At Rally, most of our teams do daily standups, but I don’t see any of them following the traditional three-questions format. Most of these teams stand around a kanban board and then talk, right to left, about what needs to be done to move items forward. It doesn’t take long; the meeting is focused on the work, not the people, and the teams walk out the door with a clear plan every day.
photo via Flickr, Creative Commons
This approach doesn’t ensure everybody talks. But over time, it’s obvious who’s involved … and who’s not.
Is it time for your team to stop going through the motions of the three questions in your daily standup, and start focusing on the work again?
Learn more about Standups, Scrum, and other Agile fundamentals with the Chalk Talk video series.Alex Pukinskis
I published a Pragmatic Manager yesterday to my subscribers. Normally, I let them enjoy the pleasure of being “in-the-know” about what I have to say this month for a while before I post the emails to my site.
Read the Pragmatic Manager here: Standup or Handoff.
However, I made a Big Mistake in where I will be speaking this week. I fat-fingered July 10 into July 19. What made it into the newsletter was July 19. Oops. I’m actually a panelist this Thursday, July 10, at Agile New England. The topic: Agile: Massive Success or Empty Buzzword?
My fellow panelists are Ken Schwaber and Linda Cook. We will have no shortage of opinions!
For example, I suspect that Ken and I might disagree on this very issue, of whether you can do agile with a geographically distributed team, and if you can have handoffs or you must do standups.
If you are near the Boston area, this Thursday, July 10, and want to see some sparks fly—or at least engage in lively debate—come to the Agile New England meeting July 10.
If you’re wondering how did this get past my reviewers, my copyeditor, and me? Well, we all make mistakes, don’t we?
Let's look at how traditional companies address the problem of new product creation: When a traditional car manufacturer designs a new transmission, they build a new factory. Step one is to negotiate with various political districts for optimal conditions, e.g. access to roads & power, conditions for taxation, etc. Then they acquire the land, build the facility, hire and train the workforce, and configure the line. After many years of preparation, their customers can finally order a product for delivery.
How do you compress years of lead time down to a one week delivery cycle?
This Principle involves making the mass-manufacturing line flexible, so it can produce different products within a 7 day sprint. These products might be existing products, modified products or completely new products.
Achieving this operational flexibility might mean additive or subtractive rapid prototyping machines, or both. It might mean some machines or lean cells are placed on lockable casters so they can be wheeled in or out of the flow depending on the sprint goal. This often means that the team reconfigures the machinery following daily Scrum each morning. And this always means test fixtures connected to andon lights at all stages of the line.
R&D belongs at the head of the line. If the new product design team is within earshot of the volume manufacturing line, bi-directional communication occurs. If the R&D group deploys to the production line every sprint, both teams can work together to reconfigure the line to test and produce the new product. As cross functional skill grows, any separation between the R&D and manufacturing team dissolves and we simply have the cross-functional product team. Each individual has specializations, welding certifications for example, but through pairing they work on every aspect of the product flow from idea to customer delivery and support.
How are you going to get a truly marketable product, if you only have seven days to create a new product? See XM Principle 5: Iterate the Design. The objective is to create a first version within a week. Then iterate on the design to improve it as needed. Use the intermediate results to get feedback from customers, users and other stakeholders. Early designs will be big and clunky, making use of off-the-shelf components, but as you iterate the design and get feedback on it, you will zero in on your target.
For services, the story is exactly analogous. Ideally the service providers are the advanced marketers and innovators of new services, and within a sprint they interact with customers to improve the service and make the improvements available to the customers.
Next: XM Principle 9: Scaling Patterns
The 10 Principles of Extreme Manufacturing
This article was written by Joe Justice and Peter Stevens.
I was a QA Lead back in the mid 90’s for a couple of years, before any of this fancy Agile stuff really started taking off. Waterfall all the way back then; mostly manual testing, with full regression cycle at the end. Hurry up and wait, then go like hell given some ridiculously small window of time remaining before we had to release to Production. We started to dabble with automated testing tools, but they were difficult to use at the time; you almost needed to be a programmer. But a lot has changed since then.
What I learned more recently, in making the move to Agile testing methods and away from these more traditional QA functions, is that it’s a really big undertaking.
For those Testers out there who have yet to really dive into the deep end of the pool with Agile testing, let me just tell you this… you have never been so important in this new Agile world.
I think it’s this ‘whole team’ approach that’s probably the biggest difference between Agile and Traditional Waterfall development.
As an Agile Tester, you’re a full-fledged, first class member of the Agile Team. All for one and one for all!
You may be saying to yourself… “That sounds nice. And I don’t disagree on the Three Musketeers cheerleading you’re doing here, but I’ve heard that before. Be a bit more specific; What does it ‘really’ mean to be an Agile Tester?”
OK, allow me to elaborate…
For starters, it means that as an Agile Tester, you actively participate in planning, estimation, scheduling, retrospectives and any other activities of the team. You’re no longer in a QA silo where you only come out to play near the end of a project or release.
It also means you’re not the only one on the team who can test, anybody can. But no need for concern; you’re still the best equipped to do so. In other words, you’re job isn’t going anywhere. And more good news; you have help when you need it.
It means that you embrace change; you collaborate well with your team members as well as those outside the team.
It means you know how to help other folks on the team automate tests and help drive exploratory testing.
It means you put yourself in the customer’s shoes, and understand where they’re coming from, what their needs are. You’re empathetic, and can see the big picture.
It means you possess a unique perspective in the way things should work, and can help identify any potential roadblocks and dependencies sooner rather than later.
It means you guide other folks on the team, helping them improve upon their testing knowledge.
It means you work closely with the developers, sharing your skills and knowledge with each other; developers helping testers with some of the more technical aspects of creating automated tests, for example.
It means you work closely with the Product Owner, guiding and helping them understand the acceptance criteria, and final verification of what it means for a user story to be ‘done’.
It means you’re involved heavily in the design of the user story’s test cases prior to Sprint Planning. This helps your Sprint Planning Meetings go more smoothly. You groom your test cases in much the same way a Product Owner grooms their product backlog.
It means you’re an explorer. You’re systematic in the way you work, you pursue anomalies, and you think about what folks on both ends of the spectrum would do.
It means you radiate information. You open the doors and provide visibility into all testing activity. Things like ‘Testboards’ that display test status and progress, defects reports, impediments, trends, etc.
It means you’re heavily involved in the estimation process, helping folks understand the acceptance criteria for the user stories, and helping to refine them along the way.
It means you actively participate in Sprint Planning, identifying individual testing tasks. Things like preparing the testing data, executing the tests, exploratory testing, test automation, etc.
It means you help the Team decide what it means for a story to be ‘done’. Things like… code complete, unit tests written and executed, integration tested, performance tested, documentation completed, etc.
It means you understand and can articulate the difference between an ‘issue’ (a problem that occurs ‘during’ the Sprint and it coupled to a user story that hasn’t yet met its definition of done) and a ‘bug’ (identified ‘after’ a user story has been completed and accepted by the Product Owner). Bugs are included in and prioritized in the Product Backlog Item. Issues are not.
In particular, it means you understand the 2nd line item in the Agile Manifesto very well (working software over comprehensive documentation). Meaning you get the importance of face-to-face communication over formal documentation of all bugs. Be lean.
It means you address issues head on. We all know the sooner an issue is found, the cheaper it is to fix it. Make sure you practice this, and the folks on the team do too, and put it into practice.
It means you understand the importance of automation, and help the team put into practice stuff like automated testing, continuous integration, build-deploy automation, and continuous delivery.
And yes, it means you actually run tests too, whether they’re automated or manual.
Yea, I know; this is a lot to take on. Start small. Make progress in chunks. Be empirical. Inspect and adapt.
If you’ve made the move to Agile practices, what have you found to be the biggest difference when it comes to testing? What are some of your biggest struggles?
At the engineering level, Extreme Manufacturing employs Continuous Integration Development (CID) to run their test suite frequently (see principle 3, Test Driven Development). Continuously Deployed Development (see principle 8) ensures a tight collaboration between product creation and product manufacturing, so the goal of never being more than 7 days from releasing an improved product can be achieved.
Continuous Integration Development (CID) ensures that the test suite is automated as much as practical, so that every time a team member sends in an updated design, an extensive test suite is run automatically.
Every time a team member uploads a new 3d drawing to DropBox, Box.net, Windows SkyDrive, or any of the file sharing technologies in use, WIKISPEED run tests. WIKISPEED can simulate crash tests and stress tests on the part using FEA (Finite Element Analysis) and a software package like LS Dyna or AMPStech. WIKISPEED can simulate airflow, aerodynamics, fluid flow, heat transfer, and electrical propagation using CFD (Computational Fluid Dynamics).
These tests can be run automatically whenever a new CAD shows up, and write out a 1 page report with a list of red or green lights. Green lights mean the test is same or better than the current version, or passes an explicit test for that part or module.
In this way, team members from all over the world can simultaneously contribute in parallel with very different ideas for improvements to each module. And it’s easy to know what the current best part is; the version of record is whatever part in CAD has passed all tests with the most green lights.
WIKISPEED includes tests for simplicity and low cost, along with user ergonomics, maintainability, manufacturability, and conformance to interface(s) of the module they are a part of.
Next: XM Principle 8: Continuously Deployed Development
The 10 Principles of Extreme Manufacturing
After an unexpectedly long break, I am now finishing up the series on Extreme Manufacturing! This post was written by Joe Justice and Peter Stevens.
Als Takeuchi und Nonaka vor bald 30 Jahren das Wort “Scrum” für Produktentwicklung in den Mund nahmen, dachten sie an alles außer Software. Ihre Referenzen waren 3M, Canon und Fujitsu – allesamt Hersteller von physischen Produkten. Und doch stand die Jahrtausendwende ganz im Zeichen der agilen Softwareentwicklung.
In den letzten Jahren beobachten wir eine Trendwende. Unternehmen in hoch innovation Branchen wie Medizintechnik, Automobil oder Sensorik und Messtechnik stellen auf agile Entwicklung um. Der Grund dafür liegt auf der Hand – diese Unternehmen stehen vor ganz ähnlichen Problemen wie die Softwareentwicklung damals:
- Die Entwicklungsgesschwindigkeit kann mit dem Veränderungstempo am Markt nicht mehr mithalten. Früher konnten Konzepte monatelang ausgearbeitet, bewertet und dann wieder überarbeitet werden. Bis die Entwicklung anfing, konnte viel Zeit ins Land gehen. Heute gilt: Je früher sich ein Konzept als unmachbar erweist, desto besser. Deshalb setzt Scrum auf die Verifikation des Designs innerhalb von kurzen Iterationen, etwa anhand von Prototypen oder virtueller Integration der Baugruppen. Indem Konzept und Entwicklung Hand in Hand gehen, können Holzwege schnell identifiziert werden – das technische und fachliche Risiko wird nach der Devise “fail early and often” ganz zu Beginn angegangen.
- Außerhalb der Projektwelt gibt es die wirkliche Welt – und diese hat die dumme Eigenschaft, sich nicht immer an Lasten- und Pflichtenheft halten zu wollen. So enstehen selbst spät im Projekt noch neue Anforderungen, die viele Seiten eines sorgfältig ausgearbeiteten Konzepts obsolet machen können. Mit Scrum machen wir das anders: Das Product Backlog listet alles auf, was für das Produkt gebraucht wird. Auch die Rahmenbedingungen (z.B. die Größe des Gehäuses, die Anzahl der Buchsen oder der Preis) sind dort bisweilen akribisch genau fest gehalten. Und dennoch ist das Product Backlog kein abschließendes Dokument. Alles, was zu Beginn noch nicht geklärt sein muss, wird bewusst offen gelassen, um es dann vor der Implementierung im Detail festzulegen. Kommen also neue Anforderungen dazu, die die Rahmenbedingungen nicht wesentlich verletzen und auch keine größeren Umbauten erfolgen, sind Änderungen ein leichtes Ding: Das Backlog enthält einen neuen Punkt, der dann zur gegebenen Zeit mit dem Team spezifiziert wird.
- In einem Punkt sind die Softwareentwickler uns voraus: Durch Testautomatisierung auf Systemebene können sie jede Veränderung sofort auf ihre Auswirkungen für das Gesamtsystem prüfen. Das ist in der Hardware schwieriger. Dort werden Modifikationen häufig nur modular getestet – erst zum Schluss, wenn Änderungen am Prototypen kaum noch bezahlbar sind, ist das Verhalten des Gesamtsystems verifizierbar. Scrum sagt hierzu: Suche dir ein Team, das gemeinsam in der Lage ist, das Produkt in nur zweiwöchigen Iterationen selbständig weiter zu entwickeln. Das bedeutet, dass ein Entwickler auch Konstrukteur sein muss – und umgekehrt. Das bedeutet auch, dass Mechanik und Elektronik Hand in Hand arbeiten müssen, damit sie das Zusammenspiel der Komponenten in Echtzeit verifizieren können. Ähnlich eng muss die Verzahnung zwischen Firmware und Elektronik bzw. Hardware sein. 3D-Drucker und Fräsmaschinen erlauben die schnelle Herstellung von Prototypenteilen. Mit Open Source Hardware kann schon heute auf eine Reihe von existierenden Designs für Testzwecke zurück gegriffen werden. Das agile Hardware-Labor ist eine der großen Herausforderung für Scrum in der Hardware.
Takeuchi, Hirotaka und Nonaka, Ikujiro: The New New Product Development Game. Harvard Business Review, January February 1986.
The Product Owner Camp in Switzerland #POCampCH will be a 2 day open space event. It is a non-profit community event and this will be reflected in the prices.
I expect it will be held during the first or second quarter of 2015, that it will be in some nice location in the mountains, or at least away from a city, and I expect there will be one or more some optional workshops on Product Ownership around the event.
With this call for participation, I am looking to confirm these expectations, find out who wants to come, who is willing to contribute, and get some guidance for key decisions about the venue and possible non-open space program (workshops or courses).
Are you interested in participating in or organizing the open space Product Owner Camp Switzerland? Sign up below!
Companies doing agile transformations must empower their development teams or Product Owners to say no. No is important, it is also very final. It implies that you can’t have whatever it is that you want. That is not an answer that Product Owners, trying to keep customers happy can go back to their customers or bosses with. Joanne Perold discusses better ways in which to have those conversations…..more.Leading Self-Organising Teams
Leading Self-Organising Teams is an interactive classroom-based masterclass providing state-of-the-art tools and practices for Lean/Agile organisations. You will learn and apply core skills underpinned by principles and values. Get equipped now to face the complex leadership challenges of the 21st century.
A past participant of the Leading Self-Organising Teams course, Theo Bohnen, has written a great review. Follow this link to read what he had to say.
Dillon Weyer and Angie Doyle will be running a half day workshop at BASSA 2014 (Business Analysis Summit Southern Africa) on the 16th Sept 2014. The topic for the workshop is “Vision: Making a good team GREAT”.
For more information and to register for this event, please visit BASSA 2014.Interesting Links
AgileLib.Net has successfully created a shared learning environment where agile practitioners can learn from one another. This website provides a library of books, blogs, articles, white papers, videos, slide shows, free tools, groups, community forums, and other resources to aid agile practitioners. Scrum Sense is proud to be a sponsor of such an excellent learning resource!Upcoming Courses
Certified Scrum Master (JHB) - Fully booked!
08-09 July 2014
FNB Conference & Learning Centre, Sandton
Certified Scrum Product Owner (CPT)
21-22 July 2014
Steenberg Hotel, Cape Town
Certified Scrum Master (CPT)
05-06 Aug 2014
Steenberg Hotel, Cape Town
Certified Scrum Master (JHB)
02-03 Sept 2014
FNB Conference & Learning Centre, Sandton
Leading Self-Organising Teams (JHB)
16-17 Sept 2014
FNB Conference & Learning Centre, Sandton
The post News update 2014/07 – Learn how to lead self-organising teams appeared first on ScrumSense.
Software development companies have been using real-time online communication tools for about 10-15 years by now, and it’s hard to imagine how they could possibly do without such tools at all. Online collaboration started out first as instant messaging, back in the late 90′s – early 2000′s. With distributed teams and with work outsourced to other parts of the world, instant messaging became indispensable. Be it a development team located thousands miles away from an executive team, or from a customer support team, or whether an organization needs an online hub where the remote workers can get together, no one questions the need for such tools and the value they bring to the workflow. However, online messaging has always been a subject to productivity-related concerns, and for a reason. I want to look into how the real-time online communications at work evolved over the last 15 years, how it was early on, what has changed now, and what we need to do about those changes, as stakeholders, or as employees if we want to be productive and feel good about our work.Instant messaging at work in the early-mid 2000′s: Block and Spy
In early 2000′s workplace culture was more restrictive and prohibitive, in general, than nowadays. Some companies used the punish-and-fear practices with regard of instant messaging at work: they would log ICQ chats, banning any chatter unrelated to work altogether, or they would go as far as to totally block instant messengers. A point to note: there was no Facebook in the early-mid 2000′s. Instant messaging just started out, and I’m old enough to remember how it seemed to be one of those technological miracles. People were soo eager to chat online with their friends when at work. The employers, naturally, wanted to keep their employees working and working. The practices of material production were implanted to software development back then. They assumed, mostly, that knowledge workers should work by the same token as machines in the manufacturing: 9-5 and non-stop. Back at those times, the issue of productivity with instant messaging at work was about not letting people get distracted. To get an idea of how it was back then (or to refresh the memories), we can refer to this 10-year old article in Wall Street Journal. Someone would probably smile, as they read this, quoting from the article: “Being overly casual with colleagues and superiors is one of the biggest pitfalls of using instant messaging.”The rise and decline of Facebook in the mid 2000′s – early 2010′s
By mid 2000′s this dynamics was replaced by a new one. Enter Facebook, going mainstream in about ’07-08. No doubt, Facebook has influenced the way we live our lives, let alone our communications with friends and co-workers. Some employers sensed trouble as early as then and blocked access to Facebook in their companies. But these attempts were futile, because the general public opinion tended to regard such actions as the Draconian culture-of-fear measures. 5-7 years later, one can observe yet another change. Now numerous studies and research prove that Facebook makes people unhappy, and they give a detailed account of how exactly this happens. I reckon the recent notorious psychological experiment conducted by Facebook is a clear proof that they sense trouble and look for the clues on how to keep people hanging out there. Otherwise, the Facebook’s game might be over. Anyway, back to to my story.The Facebook-ization of workspace
Facebook, as outstanding a phenomenon in public life as it is, has certainly influenced the way companies arrange their online communications. Before Facebook, it was about instant messaging. In the age of Facebook, real-time communication at work has got more and more Facebook-ized. Now these tools are not “instant messengers”, they are referred to as the tools for “team collaboration, file sharing, document sharing, social sharing”. Can you feel the difference? Now, let’s think logically: if research proves that Facebook makes people unhappy, and given that real-time collaboration tools have acquired many Facebook-ish traits, it is safe to assume that teams might be subjected to this same unhappiness and feeling low as they use such tools, similarly to how it happens with Facebook users! So, which Facebook-like peculiarities of online team collaboration tools do we need to keep an eye on? Where’s the potential danger of unhappiness and unproductiveness?Miserable observer vs. energetic doer
As the research has it, one of the most insidious traps associated with Facebook, on a psychological level, is spending more time in passive than in active mode. The more time we spend browsing photos and passively checking updates, the worse it feels. Same with the real-time team collaboration tools. Once we spend a lot of time passively checking status updates of our co-workers, on how something worked great or sucked in an area of work which is beyond our control, a certain cognitive bias of being let out of the real action is slowly formed. It might feel that our work doesn’t matter at all. There’s a nagging voice that says: “All my efforts are in vain, no one needs them.” In a bounceback fashion, these people will want to stand out and make a difference. But their work is not related to any major achievements. They just do their job, as a tech support engineer, or as a QA engineer, or as a software developer. Still, they feel alienated, under the influence of this bias, and they will act Facebook-ishly to remind the rest of the world that their work matters. They’d post an update that — in their mind influenced by the bias — would make their work appear meaningful. But this update wouldn’t add value to the work of others in the team. Or, they might tend to be overcritical as to how things work, or how something is eternally wrong. I do not mean the exchanges where the team collaborate online to resolve an urgent issue real-time. My point is that these channels of communication have to be arranged thoughtfully, and engage those employees that can be the doers in such situations, rather than passive observers. I’ve given just some examples of the distortions produced by those biases. Let alone that this vicious “feeling low+the need to compensate” circle creates a swirl of alienation, its contribution to the team’s productivity is zero. If an employee is preoccupied with this unhealthy virtual environment, and tends to act in a Facebook-ish fashion, they do not do the work. They blow their productive focus and their mental energy on coping with such psychological biases.What to do about Facebook-ish biases?
If something like that happens in your team, fingerpointing and spotting individual point of failures will not help. People are people, we have emotions and visceral reactions. The only way to go forward and to keep us productive, energetic and healthy at work is to sit down, think and come up with the strategic setup for internal communications. Who in the team needs to collaborate real-time to do their job? For whom online collaboration is more of a waste, loaded with potential biases? If someone needs some information, could there be such a setup, where they’d get this info async? If this info is available, how do we make sure that everyone knows where to get it? These are just some questions that one needs to answer. If you’re a a stakeholder, or a person in charge of the mechanics by which your company runs, there’s a compelling evidence that calls to de-Facebook-ize work-related communications. If we think more about it, the real-time messaging is usually required for customer-related issues. It could be, a tech support team urgently needs help from developers or from the dev ops. But do they need to include other people from QA and dev to these firefighter talks? Gee, if the production team see that customers always come complaining, they might get a bad cognitive bias that no matter how hard they work, customers still have issues. The rule of a thumb is: think who needs which information to do their work, rather than “why don’t we keep everyone informed real-time?” Biases developed from spending time in passive-observer mode come with a price tag: dissatisfaction with work, loss of productivity, and a whole array of other such bad things, which no sensible person, be it an employee or a business owner, would want to have in their organization. If you are an employee, think if you want to stay on top of all the updates real-time. Beware passive browsing. It’s the most dangerous thing ever about anything online. If your management has no policy for real-time collab tools, invent it for yourself. When you start feeling bad being a passive observer, and catch yourself posting notes with negative or sarcastic messages, run away. Shut down those channels, and focus on your own work.
Slack, an online team collaboration tool, displays some cheerful messages for its users. One of these messages is particularly wise and well-intentioned. Here’s how it goes: “Enjoy Slack responsibly“. Also, Slack has a slogan on their web-site: “Be less busy”, which I would like to extend: “Be less busy. Be more focused instead“.
Angie Doyle and myself will be running a half day workshop at BASSA 2014 (Business Analysis Summit Southern Africa). The topic for our workshop is “Vision: Making a good team GREAT”.
About the workshop:
“Teamwork is the ability to work together towards a common vision. The ability to direct individual accomplishments towards organisational objectives. It is the fuel that allows common people to attain uncommon results.”
– Andrew Carnegie
Research has proven that a key ingredient of any successful team is a shared vision. When each team member knows that they are doing something of value and that their individual contribution is essential for the success of the team, they are more committed to the result. Join us for an interactive session where you will learn how to create and communicate a company, product or project vision using the following tools and techniques (and more): – Elevator Statement: communicate the vision in less than 30 seconds (the average time span of an elevator ride) – Product Vision Board: Validate your ideas and assumptions about the target group, user needs, key product features and value the product should deliver – Vision Box: If your product or initiative were marketed in a box, what would it look like? These tools and techniques are suitable for teams in both an Agile and Waterfall environment and will encourage participation from even the most challenging stakeholder!
The main takeways from the workshop:
- Get practical hands-on experience using all of the above techniques
- Discover the OMG (Object Management Group) Business Motivation Model and learn the difference between “Mission” and “Vision” and how “Courses of Action” help to attain “Desired Results”
- Defining the business need and vision is a key task of the BABOK Enterprise Analysis knowledge area and a critical part of any business analysis effort. Use these techniques as an alternative to the options available in the BABOK
For more information or to register for the event, please visit BASSA 2014.