Skip to content

Feed aggregator

Von Zahlenfetischismus und anderen Angewohnheiten

Scrum 4 You - Mon, 04/07/2014 - 07:49

Letztens im Sprint Planning 1: Der Product Owner stellt gerade die 7. Story vor. Bereits das Commitment der 6. Story hatte einigen Teammitgliedern Bauchschmerzen bereitet. Doch zu meiner Überraschung ist das Team schnell zu dem Entschluss gekommen, auch diese weitere Story zu committen.

Szenenwechsel: Die Nachbesprechung des Meetings in kleinem Kreis. “Warum wart ihr euch als Teammitglieder bei der letzten Story so sicher?”, lautet meine Frage als ScrumMaster. Kleinlaut wird mir erklärt, dass ein Teil der Storys vorab im Aufwand mit Manntagen geschätzt wurde. Und das alles, nachdem wir die letzten Schätzungen mit Hilfe von Magic Estimation [1] auf der Basis des relativen Funktionsumfangs sehr effizient durchgeführt hatten und das Team überzeugt von den Vorteilen wirkte.

Das Beispiel zeigt, wie schwierig es doch ist, alte Gewohnheiten hinter sich zu lassen. Obwohl mir doch in den Diskussionen mit dem Team bestätigt wurde, dass alle bisherigen Aufwandschätzungen keineswegs genau und richtig waren. Zudem sind viele der traditionellen Software-Schätzverfahren mit hohem Aufwand verbunden, da viele Faktoren erhoben und Bewertungen durchgeführt werden müssen, wie beispielsweise in der Function Point Methode [2]. Und doch scheint es schwierig zu sein, die alten Angewohnheiten einfach einmal beiseite zu legen.

Doch was ist es, das uns an den Schätzungen mit Aufwand festhalten lässt? Ist es das Gefühl der vermeintlichen Sicherheit, die Größe der Story bestimmt zu haben? Ist es die Annahme, das Projekt mit Hilfe dieser Zahlen „im Griff“ zu haben? Oder ist es der reine Zahlenfetischismus, der von Jahr zu Jahr zuzunehmen droht? Oder sind es ganz andere Gründe, die wir gar nicht benennen können?

"Man kann die Ideen, wie sie in unserem Geiste und in der Natur sich kundgeben, sehr treffend durch Zahlen bezeichnen; aber die Zahl bleibt doch immer das Zeichen der Idee, nicht die Idee selbst. Der Meister bleibt dieses Unterschieds noch bewusst, der Schüler aber vergisst dessen und überliefert seinen Nachschülern nur eine Zahlenhieroglyphik, bloße Chiffren, deren lebendige Bedeutung niemand mehr kennt und die man mit Schulstolz nachplappert." Heinrich Heine

Mein Tipp: Lasst euch auf neue Methoden ein, wenn die bisher verwendeten keinen Erfolg versprechen. Lasst euer Bauchgefühl entscheiden und verschwendet keine Stunden und Tage für kompliziert berechnete Schätzungen, die nicht halten. Benutzt Magic Estimation, mit dessen Hilfe ihr die Storys schneller und fokussierter schätzen könnt. Ich bin mir bewusst, dass dies auch Mut erfordert. Den Mut, bisher jahrelang verwendete Verfahren in Frage zu stellen. Glaubt mir, es lohnt sich!

[1] Gloger, B.: Scrum. Hanser Verlag (4. Auflage), 2013.
[2] Poensgen, B.: Function-Point-Analyse: Ein Praxishandbuch. dpunkt Verlage (2. Auflage), 2012.

Übrigens frisch im Buchhandel: “Wie schätzt man in agilen Projekten – oder wieso Scrum-Projekte erfolgreicher sind” von Boris Gloger. Hanser Verlag 2014.

Related posts:

  1. Magic Estimation / Great Article
  2. Agile Estimation
  3. Magic Estimation / Toller Artikel von David Campey

Categories: Blogs

install4j and AppleScript: Creating a Mac OS X Application Bundle for a Java application

Mark Needham - Mon, 04/07/2014 - 02:04

We have a few internal applications at Neo which can be launched using ‘java -jar ‘ and I always forget where the jars are so I thought I’d wrap a Mac OS X application bundle around it to make life easier.

My favourite installation pattern is the one where when you double click the dmg it shows you a window where you can drag the application into the ‘Applications’ folder, like this:

2014 04 07 00 38 41

I’m not a fan of the installation wizards and the installation process here is so simple that a wizard seems overkill.

I started out learning about the structure of an application bundle which is well described in the Apple Bundle Programming guide. I then worked my way through a video which walks you through bundling a JAR file in a Mac application.

I figured that bundling a JAR was probably a solved problem and had a look at App Bundler, JAR Bundler and Iceberg before settling on Install4j which we used for Neo4j desktop.

I started out by creating an installer using Install4j and then manually copying the launcher it created into an Application bundle template but it was incredibly fiddly and I ended up with a variety of indecipherable messages in the system error log.

Eventually I realised that I didn’t need to create an installer and that what I actually wanted was a Mac OS X single bundle archive media file.

After I’d got install4j creating that for me I just needed to figure out how to create the background image telling the user to drag the application into their ‘Applications’ folder.

Luckily I came across this StackOverflow post which provided some AppleScript to do just that and with a bit of tweaking I ended up with the following shell script which seems to do the job:

#!/bin/bash
 
rm target/DBench_macos_1_0_0.tgz
/Applications/install4j\ 5/bin/install4jc TestBench.install4j
 
title="DemoBench"
backgroundPictureName="graphs.png"
applicationName="DemoBench"
finalDMGName="DemoBench.dmg"
 
rm -rf target/dmg && mkdir -p target/dmg
tar -C target/dmg -xvf target/DBench_macos_1_0_0.tgz
cp -r src/packaging/.background target/dmg
ln -s /Applications target/dmg
 
cd target
rm "${finalDMGName}"
umount -f /Volumes/"${title}"
 
hdiutil create -volname ${title} -size 100m -srcfolder dmg/ -ov -format UDRW pack.temp.dmg
device=$(hdiutil attach -readwrite -noverify -noautoopen "pack.temp.dmg" | egrep '^/dev/' | sed 1q | awk '{print $1}')
 
sleep 5
 
echo '
   tell application "Finder"
     tell disk "'${title}'"
           open
           set current view of container window to icon view
           set toolbar visible of container window to false
           set statusbar visible of container window to false
           set the bounds of container window to {400, 100, 885, 430}
           set theViewOptions to the icon view options of container window
           set arrangement of theViewOptions to not arranged
           set icon size of theViewOptions to 72
           set background picture of theViewOptions to file ".background:'${backgroundPictureName}'"
           set position of item "'${applicationName}'" of container window to {100, 100}
           set position of item "Applications" of container window to {375, 100}
           update without registering applications
           delay 5
           eject
     end tell
   end tell
' | osascript
 
hdiutil detach ${device}
hdiutil convert "pack.temp.dmg" -format UDZO -imagekey zlib-level=9 -o "${finalDMGName}"
rm -f pack.temp.dmg
 
cd ..

To summarise, this script creates a symlink to ‘Applications’, puts a background image in a directory titled ‘.background’, sets that as the background of the window and positions the symlink and application appropriately.

Et voila:

2014 04 07 00 59 56

The Firefox guys wrote a couple of blog posts detailing their experiences writing an installer which were quite an interesting read as well.

Categories: Blogs

A New Local Agile Conference: TriAgile!

Agile Artisans - Mon, 04/07/2014 - 02:00
There's a great annual conference coming to RTP for the first time on May 2nd. The stellar speaker lineup includes:

And that's only about half the list! See the entire list here.

Categories: Companies

Clojure: Not so lazy sequences a.k.a chunking behaviour

Mark Needham - Mon, 04/07/2014 - 00:07

I’ve been playing with Clojure over the weekend and got caught out by the behaviour of lazy sequences due to chunking – something which was obvious to experienced Clojurians although not me.

I had something similar to the following bit of code which I expected to only evaluate the first item of the infinite sequence that the range function generates:

> (take 1 (map (fn [x] (println (str "printing..." x))) (range)))
(printing...0
printing...1
printing...2
printing...3
printing...4
printing...5
printing...6
printing...7
printing...8
printing...9
printing...10
printing...11
printing...12
printing...13
printing...14
printing...15
printing...16
printing...17
printing...18
printing...19
printing...20
printing...21
printing...22
printing...23
printing...24
printing...25
printing...26
printing...27
printing...28
printing...29
printing...30
printing...31
nil)

The reason this was annoying is because I wanted to shortcut the lazy sequence using take-while, much like the poster of this StackOverflow question.

As I understand it when we have a lazy sequence the granularity of that laziness is 32 items at a time a.k.a one chunk, something that Michael Fogus wrote about 4 years ago. This was a bit surprising to me but it sounds like it makes sense for the majority of cases.

However, if we want to work around that behaviour we can wrap the lazy sequence in the following unchunk function provided by Stuart Sierra:

(defn unchunk [s]
  (when (seq s)
    (lazy-seq
      (cons (first s)
            (unchunk (next s))))))

Now if we repeat our initial code we’ll see it only prints once:

> (take 1 (map (fn [x] (println (str "printing..." x))) (unchunk (range))))
(printing...0
nil)
Categories: Blogs

Agile Progamming for Families

Scrum Log Jeff Sutherland - Sun, 04/06/2014 - 10:17

New York Times columnist and author Bruce Feiler has just published a new book titled: The Secrets of Happy Families: Improve Your Mornings, Rethink Family Dinner, Fight Smarter, Go Out and Play, and Much More.  The secret it turns out is applying agile development to your household. 
Every week starts with a family meeting. Kids and parents self-organize and self-manage (kids even help decide on their own incentives and punishments) and every week they have a retrospective to determine what they can do better next Sprint. Turns out that kids think their parent’s stress levels can improve.
Scrum: savior of the modern American family? Watch and decide for yourself. 


You can listen to an NPR review and an interview with Bruce Feiler here and here.
Wanna learn more about Agile and childhood?  Click here for Scrum in schools.
-- Joel Riddle
Categories: Blogs

The Growth Mindset: A Key to Resilience, Motivation, and Achievement

J.D. Meier's Blog - Sat, 04/05/2014 - 21:59

Your mindset holds the key to realizing your potential.

Your mindset is your way of thinking, and your way of thinking can limit or empower you, in any number of ways.

In fact, according to Carol S. Dweck, author of Mindset: The New Psychology of Success, mindset is the one big idea that helps explain the following:

  • Why brains and talent don’t bring success
  • How they can stand in the way of it
  • Why praising brains and talent doesn’t foster self-esteem and accomplishment, but jeopardizes them
  • How teaching a simple idea about the brain raises grades and productivity
  • What all great CEOs, parents, teachers, athletes know

When Dweck was a young researcher, she was obsessed with understanding how people cope with failures, and she decided to study it by watching how students grapple with heard problems.

You’re Learning, Not Failing

One of Dweck’s key insights was that a certain kind of mindset could turn  a failure into a gift.

Via Mindset: The New Psychology of Success:

“What did they know?  They knew that human qualities, such as intellectual skills could be cultivated through effort.  And that’s what they were doing – getting smarter.  Not only weren’t they discouraged by failure, they didn’t even think they were failing.  They thought they were learning.”

Your Can Change Your IQ

Believe it or not, a big believer in the idea that you can use education and practice to fundamentally change your intelligence is Alfred Binet, the inventor of the IQ test.

Via Mindset: The New Psychology of Success:

“Binet, a Frenchman working in Paris in the early twentieth century, designed this test to identify children who were not profiting from the Paris public schools, so that new educational programs could be designed to get them back on track. Without denying individual differences in children’s intellects, he believed that education and practice could bring about fundamental changes in intelligence.”

Methods Make the Difference

Here is a quote from one of Binet’s major books,  Modern Ideas About Children:

"A few modern philosophers ... assert that an individual's intelligence is a fixed quantity, a quantity which cannot be increased.  We must protest  and react against this brutal pessimism ... With practice, training, and above all, method, we manage to increase our attention, our memory, our judgment and literally to become more intelligent than we were before."

Growth Mindset vs. Fixed Mindset

The difference that makes the difference in success and achievement is your mindset.  Specifically, a Growth Mindset is the key to unleashing and realizing your potential.

To fully appreciate what a Growth Mindset is, let’s contrast it by first understanding what a Fixed Mindset is.

According to Carol Dweck, a Fixed Mindset means that you fundamentally believe that intelligence and talent are fixed traits:

“In a fixed mindset, people believe their basic qualities, like their intelligence or talent, are simply fixed traits. They spend their time documenting their intelligence or talent instead of developing them. They also believe that talent alone creates success—without effort. They’re wrong.”

In contrast, according to Dweck, a Growth Mindset means that you fundamentally believe that you can develop your brains and talent:

“In a growth mindset, people believe that their most basic abilities can be developed through dedication and hard work—brains and talent are just the starting point. This view creates a love of learning and a resilience that is essential for great accomplishment. Virtually all great people have had these qualities.”

If you want to improve your motivation, set yourself up for success, and achieve more in life, then adopt and build a growth mindset.

Here are a few articles to help you get started:

3 Mindsets that Support You

5 Sources of Beliefs for Personal Excellence

6 Sources of Beliefs and Values

Growth Mindset Over Fixed Mindset

Training Mindset and Trusting Mindset

Categories: Blogs

Scrum: The Necessary Conditions

Business Craftsmanship - Tobias Mayer - Sat, 04/05/2014 - 15:51

[Originally published on ThePeoplesForum 8/5/13]

The previous post Scrum: a 5-step guide for managers was (quite rightly) criticized for not describing Scrum. It was never intended to. In the text I describe the five steps as being for “managers and executives for starting a new Scrum process”. The title was intended to challenge, to have people ask, so what is Scrum?

Scrum, clearly, is the thing defined in The Scrum Guide, a lightweight document, laying out the process, roles and artifacts of Scrum, and describing the value it offers. It is—happily—very low on prescription, beyond prescribing the basic Scrum framework. There is little in there to take issue with, and actually little that has changed from original Scrum. The problem is, with this and most of the books on the subject, sparse attention is paid to the environment in which we try to implement Scrum. To me this is key to success.

I recently witnessed a team implement at least the first four of the five steps I recommend. They were not “doing Scrum” and yet were closer to the values we seek with Scrum than many teams I have witnessed struggling to make the process meaningful with members in different locations, no clear product vision, team members working on different projects, being driven (and driven crazy!) by the electronic tracking tool of (someone else’s) choice, with all its rules and limitations. Scrum can sometimes create more pain that it relieves.

Teams that are not supported—environmentally, humanely, systemically—to do Scrum, will do Scrum very poorly. Teams that are so supported may not actually end up doing Scrum at all, but will likely have better results. This is my experience from the past nine years.

So my “5 steps” are intended to have managers and executives understand the necessary conditions for inspiring an effective, engaging process, whether that’s Scrum or something else. With such conditions met, I would usually recommend something that looks very much like Scrum, with perhaps a more continuous flow model á la Kanban. As always, context will determine the detail.

And if anyone doubts my own definition of Scrum, or feels it is out of line with The Scrum Guide. Please read Simple Scrum, an essay written in 2009, which still accurately reflects my understanding of Scrum.

Original comments can be seen here

Categories: Blogs

Scrum: a 5-step guide for managers

Business Craftsmanship - Tobias Mayer - Sat, 04/05/2014 - 15:51

[Originally published on ThePeoplesForum 7/31/13]

Scrum is really very simple. Here’s a 5-step guide for managers and executives for starting a new Scrum process.

  1. Start with a clear product vision—and a visionary guide (PO).
  2. Establish a co-located, cross functional team whose members between them have all the skills necessary to build the product. [1]
  3. Create a space for the team to work in, with plenty of wall space, whiteboards, index cards, tape and sticky notes. 
  4. Introduce the team to their stakeholders and users.
  5. Get out of the way.

Even without any Scrum training, you’ll find that your team is 75% of the way to having a highly effective process. The continuous improvement part will emerge, because people working in an autonomous way, with clear purpose, want to be the best they can be.

Starting Scrum is really is as simple as this. Why do we make it so complicated. Why is each of these steps so hard—especially step 5? 

[1] Start with the smallest possible team. Let the team determine who/what skills they need to add as they progress

Original comments can be seen here

See also Scrum: the necessary conditions

Categories: Blogs

Scrum: Getting past ANALYSIS PARALYSIS and Scaling Scrum

Mike Vizdos - Implementing Scrum - Sat, 04/05/2014 - 02:57

 Getting past ANALYSIS PARALYSIS and Scaling Scrum

Hi.

I hope you are doing well and I am providing value to you with these posts (I know your time is valuable).

I am working hard at keeping them ON TOPIC (Scrum) and appreciate all the e-mails, calls, and comments when I post out here.  You are awesome.  Thank you.

The last posting I wrote (been a few weeks — bad mike)  I wrote about ASKING FOR HELP and FOCUSING.

These are two key elements I use to get past that concept of ANALYSIS PARALYSIS.

Do they work for you?

What else helps you get past it?

I know I told you I’d write about scaling scrum — because that is really becoming popular today.

Thing is… it’s NOT a new thing.  It’s just getting more and more popular as people THINK other competitors (or organizations) are successful scaling Scrum.

Here is a basic question:

What does “Scaling Scrum” mean to you?

For years, I’ve been recommending to SLOW DOWN and #DELIVER something.

One. Thing. At. A. Time.

Enterprise Scrum: Ignore THIS Advice and Fail

http://www.implementingscrum.com/2011/02/24/enterpirse_scrum_ignore_and_fail/

Scrum: You have LESS oxygen at high altitudes.

http://www.implementingscrum.com/2007/07/02/you-have-less-oxygen-at-high-altitudes/

Bond. Scrum Chicken Bond. In a Convertible.

http://www.implementingscrum.com/2007/09/30/bond-chicken-bond-in-a-convertible/

 

So.

 

What does this have to do with Scaling Scrum (or Scaling Agile)?

Think about how tough it is to start a Scrum project in a large organization… heck… in ANY sized organization.

Do some google searching on something called SAFe (TM) (Scaled Agile Framework).  Seems like it’s gaining market traction.

There are lovers and haters of the technique.

Some people called Scrum snake oil.

Some people are calling SAFe snake oil.

For me… well… you know by now I recommend people get good at Scrum before trying to scale it.

And.  That’s me.  Experience talking.

My recommendation is you READ MORE and LEARN MORE about it.

I have and will continue to do so (yes, I attended a 2 day powerpoint festival of reading slides to me).

Do your due diligence… READ about it.

Instead of getting stuck in analysis paralysis about where to start and how to start (big or small) — START.

DO.

#DELIVER.

Go.

Comments welcome!

 

 

 

 

 

Categories: Blogs

Situational Leadership and the ScrumMaster

Agile Game Development - Fri, 04/04/2014 - 20:11
After I recently posted an article called "An Introduction to Situational Leadership", I was contacted by Randy Baker.   Randy lived nearby and had worked with Dr. Paul Hershey, the developer the initial Situational Leadership (SI) model, for 20 years.

In the original article, I shared an illustration of the levels of team maturity:

I described to Randy, how the ScrumMaster role is meant to help teams reach higher levels of maturity by, at first, directing less and then delegating more.  Randy then drew the following diagram (it was, literally, on a Starbucks napkin so I've redrawn and added it to the diagram above):
The diagram shows the relationship between a leader in the SI model and the team, based on their maturity.  This diagram resonates because it matches the formations you'd observe in a Daily Scrum based on the maturity of the Scrum Team.
Scrum attempts to bootstrap a Scrum Team into the "high supportive behavior" side (top half).  Very often a studio's culture will be more directive going in, and you'll initially find teams reporting to the ScrumMaster, who is running the meeting (the "Coaching" quadrant in the upper right) at the center of a group of developers.  Over time, a good ScrumMaster will improve their facilitation skills and support (upper left quadrant) the team as an equal member, standing as a part of the team's circle.
As a Scrum Team develops their maturity and becomes more self-organizing, the ScrumMaster will delegate more of their day-to-day duties, but always observe and support the team (lower left quadrant).
Any team that finds themselves in the lower right quadrant is not "doing Scrum" yet.
Categories: Blogs

Calling All Citizen Engineers: Let’s RallyON!

Rally Agile Blog - Fri, 04/04/2014 - 16:39

We like to say that RallyON is not your typical user conference: you won’t sit and listen to a bunch of speakers drone on and on, then have to weave between advertisements and vendors in the hallways. Instead, RallyON is your chance to get actionable advice, inspiration, and best practices from the leaders, coaches, champions, and developers who make up the Rally community.

Likewise, the Rally For Impact Scrimmage -- preceding the conference on Sunday, June 8 -- isn’t going to be your typical sit-and-listen conference event: no way. Intrigued? Keep reading.

The Opportunity

The Rally for Impact Scrimmage is a fast-paced, collaborative, afternoon event that lets RallyON attendees help entrepreneurial nonprofit organizations solve real-world problems. Rally For Impact is Rally Software’s corporate social responsibility initiative, and in addition to protecting the planet and serving our communities, we also work to mobilize “Citizen Engineers.”

This scrimmage gives you a chance to be a Citizen Engineer for a day. Switch gears for a while and do well by doing good. Collaborate with a team to come up with innovative, technology-driven ideas for nonprofit organizations making a dent in some of the world’s toughest problems. Have fun AND learn rapid prototyping methods you can take back to your own company.

The Event

You’ll learn about rapid prototyping directly from a master: Tom Chi, Experience Lead at Google X. Rapid prototyping is a methodology designed to save time and money by quickly collecting and integrating user feedback on ideas for new business models, marketing messages, products, and services.

Handpicked nonprofit organizations, who are tackling tough social problems around the world, will each present a compelling challenge their organization is facing or a new idea they're itching to test. Each challenge will require a Citizen Engineer approach — using technology to solve problems with environmentally, economically and socially responsible solutions.

Next, you’ll join forces in small teams to offer your ideas, skills, and creativity to iterate on the organization’s challenge -- using your newly-acquired rapid prototyping knowledge.

Facilitators trained in Lean and Agile practices (as well as cat-herding) will keep each team on course throughout the day. Snacks, happy hour, and dinner will be provided to keep the juices flowing.

The Buzz

What do people who have “scrimmaged” before say about the experience?

“After the scrimmage I used rapid prototyping at a staff meeting. And what I saw for the the first time was 100% intellectual and emotional engagement for the entire meeting”

“We are still reeling from all the buzz and excitement from the Scrimmage. We can’t wait to bring this design approach to our teams and present all the learning we experienced to the entire organization.”

“It was awesome to have the opportunity to work on real organizations’ real-time challenges, as opposed to hypothetical situations. I will quickly add the philosophy of rapid prototyping to my own approach to idea development.”

If you’re planning to attend RallyON and you’re ready to switch gears and become a Citizen Engineer for a day, register now to join us on Sunday, June 8th, as we Rally For Impact.

Powered by

Rally For Impact   

 

  Geri Mitchell-Brown
Categories: Companies

Minor Update: Seven Essential Teamwork Skills

Learn more about our Scrum and Agile training sessions on WorldMindware.com

I was recently checking my Google Analytics for Agile Advice and the article I wrote quite a while back in 2009 about teamwork skills is even more popular than the front page of this blog!  I took a look at it and made some tweaks including providing some good references for more information about each of the teamwork skills.  Take a look: Seven Essential Teamwork Skills.  The only hard one was to find a good article about “sharing” as a teamwork skill.   If you know of one, please comment so that I can add it!  I’ll even be happy to take a link to an article you have written yourself.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
facebooktwittergoogle_plusredditpinterestlinkedinmail
Categories: Blogs

Enterprise UX: Why the Paradigm Shifts

TargetProcess - Edge of Chaos Blog - Fri, 04/04/2014 - 14:56

What is the first thing that comes to mind when we hear the words: enterprise software? Most likely it’s something bulky, cumbersome, weighty, hard to use, and something that alludes to the drudgery of a job where software seems to block our productive flow, as opposed to fostering it. You might be able to compare it to being in the middle of some fun activity, such as hanging out with a new love interest, and suddenly your ex walks in and throws a stern look your way, making the smile slowly slip away from your face.

Dull user interfaces (UIs) have lost their standings to consumer and entertainment apps that are slick, streamlined and provide fresh content at the swipe of a finger; but enterprise software will not surrender. At times it even seems that these dinosaur-like UIs will never disappear, begging the question: what will finally make them extinct?

Mockery aside, much talk has been going on for some time about how uncomfortable UIs of enterprise software are, and how vendors should start producing more personable UIs for it. No “should” in this world will turn into action, unless there’s some propelling momentum that will make it happen, and that’s exactly why we need to make these improvements.

If we take an X-ray look into the heart of the matter, why do we need a better UX? Is it for pleasure, aesthetic enjoyment, or for the feel of comfort and continuous flow? What is the ultimate element that will dictate development of a better UX?

This primary incentive is called the need for speed. We’re moving away from the era of decade-long projects and yearlong rollouts of IT infrastructures, with obnoxious RFP-based adoptions pushed down the pipe from the top of an organization. Companies that use enterprise software want it to be flexible, adaptable and quick to update, in tune with fast-changing social, technology and business trends. Enterprise software vendors will inevitably have to address these needs and deliver a better UX, making user action flow easier and more intuitive, as well as shortening the times required to retrieve all kinds of reports from the enterprise Big Data.

Focus on visualization would be the essential prerequisite for this “accelerated” UX. The enterprise software of 2014 and beyond has no room for slowness, and UX in enterprise applications is a part of a bigger picture involving many facets. In a nutshell, feedback-based development is turning mainstream for enterprise companies, who demand faster rollouts, faster scalability, faster adoption and ease-of-use. There’s no time for pompous presentations or heavily loaded trainings, where learning how to use a software is similar to musing over scholastic text.

If there’s any example of a positive UX development in the enterprise world that would be Google, of course, with their cloud services that have always offered a smooth UX. Another example that comes to my mind is Salesforce. They make a genuine effort to make UX better for their end-users. They improved their contextual help, making it easier to find answers to “how to do what” questions, and did a face-lift to the UI. Considering the fact that Salesforce is the baby of the 90’s, it’s become generally cleaner and easier-to-use, both for people who enter the sales data, and for the executives who work with the reports generated from this data.

Now, if Google and Salesforce are marching ahead as the pioneers of this enterprise UX movement, how about the mammoth companies? What is the propelling momentum that would finally deliver a slick UX to an average enterprise software user, be it ERP, supply chain management, or project portfolio management?

Enterprise startups are the fireballs to ignite these changes. An enterprise start-up is a company that would create a new generation of easy to adopt, easy to roll out, and easy to use enterprise software, to help organizations get the most of their Big Data, from an analytical perspective, and support adjustments to daily operations, fast. In the mid-2000’s we witnessed an outburst of start-ups that bent over backwards to entertain the hell out of everyone. Start-ups at that time did photo sharing, social sharing, or gamification. But we only have so many resources and time for entertainment.

Some people do not like to overshare, especially in the workplace. Teenagers and young people spend a lot of time with entertainment apps, but they’re not the ones who spend money on software. What’s more relevant for software providers are the serious companies who are ready to pay for new, nice, crisp, usable and fast enterprise products. With the security and reliability of cloud improving, startups would be better off if they apply the power of their genius not to some viral dating app but to a software that would help people do work faster and with comfort.

It may take years but fresh start-ups will shift the paradigm in enterprise UX, emerging as the competitive power to old-school companies, so reluctant to weed their overgrown gardens. It reminds me of the Newton’s first law of motion: “An object at rest stays at rest… unless acted upon by an unbalanced force.” In the case of enterprise UX, this unbalanced force — read, new technology (cloud and mobile) + changing business and social environment (need for speed) — requires start-ups to champion this change. The ball is already rolling.

It won’t help to bombard established enterprise software companies with calls to update their UX and make it more usable. In most cases, they would weigh the costs of a UX face-lift vs. gains from new business and/or keeping old clients, and decide against it. Things will change as this new unbalanced force, the enterprise start-ups, come into play. The conservatives would then have to reckon with them, and either re-invent their identity, steering the updates needed for their software (which is not an easy thing to do), or step out of the game.

*This piece was featured in @Wired on March 28, 2014

Related articles:

Do You Speak Human, Software?

The Paradigm of Project Management Tools

Why People Don’t Understand How to Use Your Software

Help People Understand How to Use Your Software

Categories: Companies

Authority and Power

Complex and Agile - Joseph Pelrine - Fri, 04/04/2014 - 13:06

One of the classic sayings in Scrum is that the ScrumMaster has no authority. He cannot tell his team members what to do, or what not to do. In a way, this makes sense. If the ScrumMaster had the authority to tell people what to do, he would take away their opportunity to take responsibility for their actions, to become committed and not just involved. Looking at it differently, by telling team members what to do, he would give them the chance to refuse responsibility for their actions. “It’s not my problem, he told me to do it!” Even though the ScrumMaster has no authority, this does not mean that he has no power.

Power cannot be taken, it can only be given. A person only has power over you if you give them this power over you. Being aware of the ways you give people power over you will help you avoid doing it unintentionally or inadvertently. So, what types of power may a person possess, and which types of power should one best focus on increasing?

In 1959, John French and Bertram Raven wrote a seminal paper on the different types of power (1959). According to French and Raven, power is defined as the potential ability of one person to influence another person. Thus, power is potential influence, while influence is kinetic power.

In their paper, French and Raven define five different types of power, all of which may vary in their domain, strength and range.

Reward power. You gives a person reward power over you when you believe that they can do something good for you or they can take away something bad. Obviously, if the person actually does do something good for you, his or her reward power over you increases.

Coercive power. You give a person coercive power over you if you believe that the person can do something bad to you, for example, cause you harm or pain. If the person actually does something bad to you, their power over you increases. The mere awareness or threat of coercive power is often enough to enforce compliance. Imagine if you were driving a car and you saw a police officer standing on the corner. Even if he was not looking directly at you, you would tend to drive slower.

Legitimate power. You give a person legitimate power over you if you believe that they have the right to have this power. This right often comes as the result of an implicit or explicit social contract. An example for an implicit social contract would be a contract that parents have with their children (although as every parent knows, this contract must be renegotiated regularly). An explicit social contract would be your work contract, which gives your boss power over you. As one can see, legitimate power contains both reward and coercive components. If you do something good at your job, you may get a bonus. If you do something bad at your job, you may get fired.

Expert power. You give a person expert power over you if you believe they have superior knowledge relevant to the situation and to the task at hand. This power rarely extends outside of the domain of expertise, but the implied transference of expert power into other domains is a technique often used in advertising.

Referent power. Referent power is the most difficult type of power to describe. It is best understood as a type of power that comes from personal integrity and/or from charisma. This is the type of power that Gandhi or Nelson Mandala or Martin Luther King had. Over time, though, the power these men had became legitimate power, as they were voted into political office.

In his later works, Raven added a sixth type of power, which he termed informational power. Having access to information, and the ability to use this information, can give a person power. As an example, think of Edward Snowden.

Looking at the different types of power, one sees that they can be grouped into two groups – positional power, which is power one receives as the result of being in a position to have the power, and personal power, which is not dependent upon position, but solely dependent upon the person. If you want to increase your power base, in order to better help people, then which type(s) of power should you focus on increasing?

Being in a position to give a reward or to coerce, or being in a position of having the right to legitimate power, puts one in the position to command others. This is not the type of power a ScrumMaster should use. This is the reason why no one who is in a management position can be a ScrumMaster for his team. It is better to focus on increasing your personal power than on increasing your positional power.

How can you start increasing your personal power? You can increase your expert power by concentrating on your continued professional development. Reading, keeping up to date on new developments in your field, attending trainings, etc., are all ways of increasing your expert power.

Increasing your referent power can be done by focusing on your continued personal development. This is a noble task whether or not you work as a ScrumMaster, since furthering your personal competencies will increase your feeling of well-being. Awartani et al. (2008) define well-being as the realisation of one’s physical, emotional, mental, social and spiritual potential.

Mental or rational well-being as that part of life which is primarily related to thinking and cognition, and to the processes of the rational mind, e.g.: planning, understanding, focusing, envisioning, abstraction, reflection, evaluation.

Emotional refers to the intrapersonal or inward-looking awareness and processing of feelings, of understanding your feelings, their triggers, and your reaction patterns, of having your emotions under control, and not being “hijacked” by them.

Social refers to the interpersonal or outward-looking awareness and processing of feelings, of understanding how they influence our interactions with others.

Physical refers to those aspects of life related to the physical senses and to sensory experience, to our bodies, and to the material and natural environments. The actions and functions of doing, building, taking apart, detailing, producing, acting, and making practical are included.

Spiritual is not necessarily a religious or esoteric concept, but refers to life, to its meaning and purpose, to beliefs and what one believes in. You are believable for others when they feel that you believe deeply and strongly in something.

Although all these aspects each play a role, well-being represents a pervasive feeling about oneself, one’s life, and one’s environment. You can start right now and take a first step towards your own well-being. Take a few moments to think about these 5 areas, where your strengths and weaknesses are, and which areas you want to focus on strengthening.

References

Awartani, M. et al. (2008) Developing Instruments to Capture Young People’s Perceptions of how School as a Learning Environment Affects their Well-Being. European Journal of Education, 43, 51-70.
French, J.R.P.Jr. & Raven, B. (1959) The Bases of Social Power. In Studies in Social Power, Ann Arbor, Michigan: Institute for Social Research, University of Michigan, pp. 150-167.

Categories: Blogs

April, April, Angsthase

Scrum 4 You - Fri, 04/04/2014 - 12:52

Der Aprilscherz ist beliebt wie eh und je. Doch während man im Privaten nach wie vor auch sein liebstes Gegenüber genussvoll ins offene Messer laufen lassen darf, lassen die meisten Medien dieser Tage eine geradezu panische Angst erkennen, man könne ihre ohnehin zumeist recht harmlosen Aprilscherze auch nur für Augenblicke ernst nehmen. Zeitungsmeldungen im schnellebigen Internet werden mit einem durch Kursivierung korrekt als redaktioneller Hinweis ausgewiesenen „April, April“ unterschrieben, Nachrichtensprecher erklären dem erstaunten Zuschauer mit geschäftsmäßigem Lächeln, er sei vermittels des eben gesendeten Einspielfilms in den April geschickt worden.

Ganz unzweifelhaft ist das Schönste an jedem Aprilscherz doch der Moment, in dem man mit einem herzlichen „April, April!“ sein Opfer darüber belehren kann, überhaupt ein Opfer zu sein. Wer labt sich nicht gerne an dieser ergötzlichen Ungläubigkeit, garniert mit einem Quäntchen peinlicher Berührtheit? Aber dazu muss der Scherz doch erst einmal glaubhaft gemacht worden sein! Das ist doch der Witz am Witz! Hier ist von Stunden, vielleicht nur Minuten die Rede, die es zum Einsickern der Fehlinformationen in die Opferhirne braucht.

Man mag in aller Breite und Ausführlichkeit über die Ursachen dieser Entwicklung im öffentlichen Raume raisonnieren, im Endeffekt aber wird es sicherlich darauf hinauslaufen, dass an verantwortlicher Stelle die akute Sorge besteht, irgendjemand könnte sich ohne unmittelbare Scherzaufklärung möglicherweise in irgendeiner Weise auf den Schlips getreten fühlen. Was aber tun?

Auf Scrumdeutsch: Commitment muss her! Wozu ist denn ein witzloser Scherz gut? Wer andere in den April schicken will, muss auch die Möglichkeit verantworten können, dadurch nicht nur positive Reaktionen auszulösen. Das ist im Voraus zu bedenken: Was für einen Scherz will ich haben? Wie wird er durchgeführt? Was will ich erreichen? Doch ist der Plan einmal gefasst und die Entscheidung getroffen, muss die Sache konsequent durchgezogen werden, denn jemanden fast in den April geschickt zu haben, ist genauso viel wert wie fast funktionierende Software oder ein fast fahrendes Auto.

Related posts:

  1. ScrumAlliance introduces Examination for CSM and CSPO
  2. 15 Minuten sind 15 Minuten
  3. Chinesen essen doch Reis :)

Categories: Blogs

News update 2014/04 – The Drama Triangle

ScrumSense.com - Peter Hundermark - Fri, 04/04/2014 - 12:29

Interested in knowing more about what the Drama Triangle is all about? Dillon Weyer of Scrum Sense discusses the Drama Triangle and how it can be used to help deal with team conflict and problem solving. Follow this link to find out more….. Kanban Foundation Level Training There are only THREE seats remaining on our Kanban Foundation Level Training […]

The post News update 2014/04 – The Drama Triangle appeared first on ScrumSense.com.

Categories: Blogs

The Dangerous Lite Side of Mindfulness and Lean

Evolving Excellence - Fri, 04/04/2014 - 08:27

By Kevin Meyer

I’ll preface this post by saying that yes, I’m from crazy California, I eat granola with fruits and nuts in the morning, am vegetarian (well, pescatarian), dislike wearing shoes, and practice yoga. At least I don’t have dreadlocks – yet. So there – now you’re warned.

I’m currently winging my way over to Hawaii’s Big Island, probably my favorite U.S. destination, and a place I’ve been to a few times a year for over a couple decades – including only three weeks ago. It’s a special place for me and especially my wife, who was born in Hilo and then eventually married me in Makena. Unfortunately this trip isn’t really for pleasure as we’ll be scattering the ashes of both of my wife’s parents, who long ago went to Hawaii on their honeymoon… and quit their jobs and just stayed. Yes, it’s that kind of place. I guess in a way we’re experiencing the circle of life, and perhaps this time closing one of its intricate loops.

Long-time readers will remember that years ago I would often escape to Hawaii on my own for a couple days to decompress and recalibrate. Solitude, silence, and the sea can do wonders when life is throwing some incredible work and personal chaos at you, as it was at me.

This is where I discovered the concepts and power of Zen, where I read Matthew May’s The Shibumi Strategy that tied it all together, and where I became human again. The chaos that had enveloped me had turned me into a bit of a neurotic mess. I created contingency plans A, B, C, and D for every possible business and personal situation, spending far more time and energy creating those multiple redundant backup plans than it would have taken to simply recover from the rare occurrence when something actually did go wrong. Learning to be mindful helped put the world into proper perspective, created a calm mind and being, thereby freeing up a tremendous amount of energy.

On the plane I’m listening to Brian Eno’s Music for Airports, a great album for calming the mind, and contemplating a couple of recent articles on mindful leadership. I’m a little concerned.

Just as lean is much more than 5S and value stream mapping, mindfulness is much more than simply being aware as a leader. A lean “transformation” based on simply implementing a set of common lean tools, without realizing it’s a holistic management system, will inevitably fail. Some lean consultants and writers, perhaps angling for the quick buck or out of ignorance, have focused on the tools at the expense of the system. Now I fear we’re seeing the same with mindfulness.

A couple days ago Maria Gonzalez wrote a piece for HBR titled Mindfulness for People Who Are Too Busy to Meditate. It’s a good article, and I agree with many of the techniques, and especially the benefits.

For instance, researchers have found that mindfulness can reprogram the brain to be more rational and less emotional. When faced with a decision, meditators showed increased activity in the posterior insula of the brain, which has been linked to rational decision making. This allowed them to make decisions based more on fact than emotion. This is good news since other research has found that reasoning is actually suffused with emotion. Not only are the two inseparable, but our positive and negative feelings about people, things, and ideas arise much more rapidly than our conscious thoughts, in a matter of milliseconds. We push threatening information away and hold friendly information close. We apply fight-or-flight reflexes not only to predators but to data itself.

She goes on to describe a concept of “micro meditation” for those who don’t want to practice full meditation. I also use “micro meditation” to re-center throughout the day. Taking just a minute to become aware of my breathing, the feeling of the steering wheel beneath my hands, or the sounds when the car radio is turned off. Just being truly aware in the moment, of your senses and emotions, without thinking about projects, people, things – or the past or the future. A minute or two is obviously easier than a full 20 to 30 minutes each morning.

As with tool-based lean, it works – temporarily and superficially. But it’s not transformative. To become truly aware and present in the moment, long term, takes a lot of very hard work. Micro meditation, as with the individual tools of lean, is just a tool. It supports the larger concept, but it is not the larger concept itself. Last week there was also an article in The Wall Street Journal on Khajak Keledjiano, CEO of Intermix, now part of Gap. Mr. Keledjiano discovered mindfulness and meditation on a dare.

A friend bet Khajak Keledjian $15,000 six years ago that he wouldn't be able to sit still for 15 minutes in complete silence. After nearly five months of trying, the 41-­year-­old CEO of high-­fashion retailer Intermix couldn't do it.

Real meditation is not just silence, it’s purposely not thinking about projects or people, the past or the present. Silencing the mind to become aware of underlying thoughts, emotions, environment, and perspectives. And it is incredibly difficult – it took me two months before I could successfully count ten breaths without my mind going off on a tangent with other thoughts. Counting ten breaths is the most basic exercise. It took a year to build my meditation practice from 5 to 10 to now 20 minutes. Here’s an introductory article, and a short but much deeper one from a more Zen Buddhist perspective. To a Buddhist, even real meditation is just a tool of a much larger belief system.

Many confuse meditation with prayer. It’s completely different – but they are very complementary. My morning practice has four components: a twenty minute (and I still struggle) period of meditation to clear the mind and become aware in the present. Then a few minutes where I focus purely on gratitude for family, friends, and blessings. That sets the stage – and perspective - for a period of prayer. Amazing how little you need to ask for when you’re present in the moment and realize how much you already have to be thankful for. Prayer then becomes focused outward, as it should be. Finally, I end with a couple minutes identifying my top two to four projects for the day. In the evening, just before bed, I usually take time for a couple minutes of hansei – reflection – on how I did with those goals and how I can improve, then a couple minutes of meditation to calm the mind, then sleep.

If you simply pause a moment to count a breath or two you don’t realize how much hard work it takes to become truly aware in the present – every moment. And, as with lean, it is still a never-ending journey – both to continually reinforce and sustain, and to improve and grow. You can easily identify someone who doesn’t get lean because they say they’ve “done lean.” The same with being mindful. You don’t “do” or become mindful – you’re continually working very hard at it.

Mr. Keledjian does work hard at it. Even with an incredibly busy schedule he makes his morning practice a priority, which is something I still struggle with. To reinforce the personal practice he takes classes at least once a week, and goes on a retreat once a year. He’s also diving into Kundalini – the yoga of the mind – and something I’ve just recently started to explore.

Mindfulness, and mindful leadership, is becoming very popular as the benefits become better known. It’s taught at the leading business schools, in the military, and on the sports fields. That’s great. But just as lean has sometimes been simplified to a set of tools in order to grab the quick short-term win at the expense of a long-term, sustained transformation, quick-and-easy mindfulness has a similar risk.

Real transformation is a journey that takes hard work and perseverance… forever.

Categories: Blogs

The Dangerous Lite Side of Mindfulness and Lean

Evolving Excellence - Fri, 04/04/2014 - 08:27

By Kevin Meyer

I’ll preface this post by saying that yes, I’m from crazy California, I eat granola with fruits and nuts in the morning, am vegetarian (well, pescatarian), dislike wearing shoes, and practice yoga. At least I don’t have dreadlocks – yet. So there – now you’re warned.

I’m currently winging my way over to Hawaii’s Big Island, probably my favorite U.S. destination, and a place I’ve been to a few times a year for over a couple decades – including only three weeks ago. It’s a special place for me and especially my wife, who was born in Hilo and then eventually married me in Makena. Unfortunately this trip isn’t really for pleasure as we’ll be scattering the ashes of both of my wife’s parents, who long ago went to Hawaii on their honeymoon… and quit their jobs and just stayed. Yes, it’s that kind of place. I guess in a way we’re experiencing the circle of life, and perhaps this time closing one of its intricate loops.

Long-time readers will remember that years ago I would often escape to Hawaii on my own for a couple days to decompress and recalibrate. Solitude, silence, and the sea can do wonders when life is throwing some incredible work and personal chaos at you, as it was at me.

This is where I discovered the concepts and power of Zen, where I read Matthew May’s The Shibumi Strategy that tied it all together, and where I became human again. The chaos that had enveloped me had turned me into a bit of a neurotic mess. I created contingency plans A, B, C, and D for every possible business and personal situation, spending far more time and energy creating those multiple redundant backup plans than it would have taken to simply recover from the rare occurrence when something actually did go wrong. Learning to be mindful helped put the world into proper perspective, created a calm mind and being, thereby freeing up a tremendous amount of energy.

On the plane I’m listening to Brian Eno’s Music for Airports, a great album for calming the mind, and contemplating a couple of recent articles on mindful leadership. I’m a little concerned.

Just as lean is much more than 5S and value stream mapping, mindfulness is much more than simply being aware as a leader. A lean “transformation” based on simply implementing a set of common lean tools, without realizing it’s a holistic management system, will inevitably fail. Some lean consultants and writers, perhaps angling for the quick buck or out of ignorance, have focused on the tools at the expense of the system. Now I fear we’re seeing the same with mindfulness.

A couple days ago Maria Gonzalez wrote a piece for HBR titled Mindfulness for People Who Are Too Busy to Meditate. It’s a good article, and I agree with many of the techniques, and especially the benefits.

For instance, researchers have found that mindfulness can reprogram the brain to be more rational and less emotional. When faced with a decision, meditators showed increased activity in the posterior insula of the brain, which has been linked to rational decision making. This allowed them to make decisions based more on fact than emotion. This is good news since other research has found that reasoning is actually suffused with emotion. Not only are the two inseparable, but our positive and negative feelings about people, things, and ideas arise much more rapidly than our conscious thoughts, in a matter of milliseconds. We push threatening information away and hold friendly information close. We apply fight-or-flight reflexes not only to predators but to data itself.

She goes on to describe a concept of “micro meditation” for those who don’t want to practice full meditation. I also use “micro meditation” to re-center throughout the day. Taking just a minute to become aware of my breathing, the feeling of the steering wheel beneath my hands, or the sounds when the car radio is turned off. Just being truly aware in the moment, of your senses and emotions, without thinking about projects, people, things – or the past or the future. A minute or two is obviously easier than a full 20 to 30 minutes each morning.

As with tool-based lean, it works – temporarily and superficially. But it’s not transformative. To become truly aware and present in the moment, long term, takes a lot of very hard work. Micro meditation, as with the individual tools of lean, is just a tool. It supports the larger concept, but it is not the larger concept itself. Last week there was also an article in The Wall Street Journal on Khajak Keledjiano, CEO of Intermix, now part of Gap. Mr. Keledjiano discovered mindfulness and meditation on a dare.

A friend bet Khajak Keledjian $15,000 six years ago that he wouldn't be able to sit still for 15 minutes in complete silence. After nearly five months of trying, the 41-­year-­old CEO of high-­fashion retailer Intermix couldn't do it.

Real meditation is not just silence, it’s purposely not thinking about projects or people, the past or the present. Silencing the mind to become aware of underlying thoughts, emotions, environment, and perspectives. And it is incredibly difficult – it took me two months before I could successfully count ten breaths without my mind going off on a tangent with other thoughts. Counting ten breaths is the most basic exercise. It took a year to build my meditation practice from 5 to 10 to now 20 minutes. Here’s an introductory article, and a short but much deeper one from a more Zen Buddhist perspective. To a Buddhist, even real meditation is just a tool of a much larger belief system.

Many confuse meditation with prayer. It’s completely different – but they are very complementary. My morning practice has four components: a twenty minute (and I still struggle) period of meditation to clear the mind and become aware in the present. Then a few minutes where I focus purely on gratitude for family, friends, and blessings. That sets the stage – and perspective - for a period of prayer. Amazing how little you need to ask for when you’re present in the moment and realize how much you already have to be thankful for. Prayer then becomes focused outward, as it should be. Finally, I end with a couple minutes identifying my top two to four projects for the day. In the evening, just before bed, I usually take time for a couple minutes of hansei – reflection – on how I did with those goals and how I can improve, then a couple minutes of meditation to calm the mind, then sleep.

If you simply pause a moment to count a breath or two you don’t realize how much hard work it takes to become truly aware in the present – every moment. And, as with lean, it is still a never-ending journey – both to continually reinforce and sustain, and to improve and grow. You can easily identify someone who doesn’t get lean because they say they’ve “done lean.” The same with being mindful. You don’t “do” or become mindful – you’re continually working very hard at it.

Mr. Keledjian does work hard at it. Even with an incredibly busy schedule he makes his morning practice a priority, which is something I still struggle with. To reinforce the personal practice he takes classes at least once a week, and goes on a retreat once a year. He’s also diving into Kundalini – the yoga of the mind – and something I’ve just recently started to explore.

Mindfulness, and mindful leadership, is becoming very popular as the benefits become better known. It’s taught at the leading business schools, in the military, and on the sports fields. That’s great. But just as lean has sometimes been simplified to a set of tools in order to grab the quick short-term win at the expense of a long-term, sustained transformation, quick-and-easy mindfulness has a similar risk.

Real transformation is a journey that takes hard work and perseverance… forever.

Categories: Blogs

Organizing a small-ish company to do Scrum and ‘regular work’

Agile & Business - Joseph Little - Fri, 04/04/2014 - 03:55

Holly asks: “I am relatively new to this methodology, but I would say I would like to learn more about how resources are assigned to Scrum teams.  Resource allocation – do Sprint team members need to spend 100% of their time in a Scrum Team?  If so, how do we account for existing job responsibilities?”

***
Good question or questions.

In simple terms, we are dying from complexity.  So, we want to keep things as simple as possible, to help people become more productive.

This is what I am thinking from what I know so far of your situation.  Imagine that your company has 800 employees, but most are ‘in the field’.  So, you have 75 people who support ‘BAU’ (business as usual), who are not ‘in the field’ and so are also potentially available to support Innovation.  And, to some degree, do need to support Innovation.

So, for 125 of the BAU people, I would have a rule that they are 80% dedicated to BAU and each person can use up to 20% of their time to support ‘innovation’.

I would maybe move 25 of the current BAU people to an Innovation group, which would include other people already doing innovation (technology people, project managers, etc.).  Then we call this the group of people doing ‘Innovation’ or ‘Change’, which now has about 75 people.

Let’s assume my ratios of BAU and Innovation people is roughly factually correct for now.  For example, it provides enough hours to do the related BAU work (if 20% of their time is also given to Innovation).  But it still raises two questions:
(a) is this the optimum ratio?
(b) should the firm be investing more (or less) in Innovation?

These two questions should be of prime interest to the Exec Team.

Note that often the Innovation people are doing work to benefit the BAU people, directly or indirectly.

These are the two main groups.  Note that the innovation people include business people also.

I would form most of the people in Innovation into Scrum Teams.  But the BAU people are NOT part of the Scrum Teams. At least not as ‘pigs’, although they may work with the Scrum Teams some as chickens (in their 20% time).

And we would group work into ‘Product Backlogs’ that have groupings of stuff that can be released quickly.  And we get a limited number of ‘projects’ or product releases in flight at any one time. In simple terms, one project per Scrum Team (per 7 people in a Scrum Team).

Obviously, we can only support, with the Innovation people that we have, a limited number of product releases at any time (in any year).

Each Innovation person is 80% dedicated to one Team (but can advise others with 20% of their time).  And the Innovation people are 100% innovation…no meaningful BAU responsibilities.  They can ‘advise’ others on BAU work in their 20% time.

It may be that some lower priority projects will ‘require’ some BAU people to be involved. But a lower priority project can only start if someone feels that they can get enough BAU support to be viable.  Or can get enough ‘business support’ elsewhere (within Innovation, via consultants, whatever).  And this will not be the case; this may represent a significant constraint on the number of inflight Innovation teams. So that some projects will be blocked until higher priority projects complete, and ‘release’ certain BAU people.

So, X project may not be able to start.  The Exec Team can decide to hire people or not, to fix that impediment.  Or, we go to the next viable priority project.  (Remember that business information can get into a Team either from Innovation people (eg, product owners or BAs or whatever we call them) or from BAU people.

Why?  We need to be focused on getting things DONE, not on how much work is ‘in process’.  We need to be focused on clear accountabilities by Team. Each Scrum Team is focused on only the one next release.  (That means the release is much more likely to get done well and quickly.)

How to form the Teams?  Here is a good option.  Have 3 managers draft up a set of teams.  And let all the Innovation people look at that and then ‘self-organize’. They can modify the proposal.  Maybe give the Innovation people a week to meet and discuss and change the proposed teams.  With the understanding that any person in a Team is 80% dedicated to that one Team, at least.  And then the 3 managers get to review the alterations and give final approval.  But the group usually does a very good job.

Usually later we discover a few things, and realize we need to make some adjustments, but the Teams usually can manage that.

The real issue is when to start and stop ‘projects’.

Whenever we have a better project than one currently in flight, we need a way to start to pause the existing project (or get it to release early) and start the higher value project. Before pausing a project, we tell the related Team, and ask them ‘we want to ‘pause’ your project…can you release most of what you have now ‘real soon’?  How soon?’  And then adjust according to their advice.

Another issue is: when does the ET know that a Scrum Team is coming ‘free’?  I give the Scrum Teams the responsibility to ‘brag’ about a Release that they are about to put out.  And they are clearly expected to release quickly, and also to release high value and high quality products.

So, when a Team has just released, it is also a time when the ET can give the Team a different ‘assignment’ or ‘mission’.  The Team may make a case that they need to stay on Product1 for the next release.  But the ET gets the final decision.

So, in this vision, the main jobs of the ET are two (for the innovation teams) 1. Fix impediments 2. Be decisive about priorities.

This last includes….when a Team finishes a release, what do we give them next?

Given where we have come from, I suspect the Team will have to say (probably repeatedly for awhile): “We are only working on one and only one release at a time…the top priority one.”

 

twittergoogle_plusredditlinkedinmail
twitterlinkedinrss
Categories: Blogs

Learnings from the Toronto Scaling Workshop

Agile & Business - Joseph Little - Fri, 04/04/2014 - 03:14

Last week we had a Scaling with Agile Workshop in Toronto.

More and more I am convinced that this scaling workshop is necessary for many people to figure out how to do Scrum well in their business situation.  They just need to work through how they will make it work in their context.  And many of the problems have to do with ‘scaling’.

Of course, not every person or team or company has ‘scaling’ problems.  So, ‘scaling’ solutions do not need to be included with Scrum (for everyone).  And of course these scaling issues vary widely and differ from situation to situation. Often in the same company.

We like to define scaling and the related words precisely.  Scaling as such, to me, is really limited to having 3 or more Scrum Teams working together on one Product.  (We use other words for the other problems that often come along with scaling or are included in ‘scaling’ by some people.)

Scaling, as we define it, still is a common problem. Often, as just suggested, many other problems come along with it. Cultural change, agile transformation, distributed scrum, etc, etc.

In the Workshop, we gave the attendees a basic framework, and an approach to defining their problems.  We tried to focus on scaling proper, but we also took questions and issues with ‘scaling’ more broadly defined.  We took their real issues.

It was impressive how different the real problems were.  Yet both were ‘scaling’.

To give them background, we discussed patterns, we discussed ScrumPLOP.org, we discussed basic and classic Scrum patterns; we discussed LeSS, and we discussed SAFe.  The key concept is: how do we try simple patterns that fit the specific needs that your situation has?  And see if we can make some progress today, and not make things overly heavy or complex.

It was impressive how, with a few key concepts, they could easily design solutions to most of their pressing problems.

One last key concept.  The real energy is inside the Team.  All the bright people running all the scaling stuff do not add any value directly. At least so far as  the customer can tell.  They may be necessary, but not essential.  So, maybe you divert some energy from the Team(s) to the ‘Scaling stuff’ for some temporary time.  But remember to focus again soon on the Team(s). Remember that the real power of scrum is in the Teams.

twittergoogle_plusredditlinkedinmail
twitterlinkedinrss
Categories: Blogs

Knowledge Sharing


SpiraTeam is a agile application lifecycle management (ALM) system designed specifically for methodologies such as scrum, XP and Kanban.