Skip to content

Feed aggregator

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

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

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

Halifax: Public Impediment List

Agile & Business - Joseph Little - Fri, 04/04/2014 - 01:00

As some of you know, I am a strong proponent of aggressively attacking the impediments. And I think it starts with a good public impediment list.

So, as examples, here are the impediments identified by the class in Halifax.

  1. Team is working on too many things
  2. No prioritized backlog
  3. Uninvolved PO
  4. Keeping everyone in the loop (not)
  5. Complexity
  6. Lack of management attentiveness
  7. Acting on retrospective improvements
  8. PO not involved
  9. Lack of understanding
  10. Silo workers
  11. Lack of impediment list
  12. Lack of retrospective
  13. Increasing Tech Debt
  14. Not having vision from PO
  15. Managing people instead of work
  16. Lack of team spirit
  17. Managing interference
  18. Unmotivated
  19. Bottom down planning
  20. Too much useless chatter (from Mgmt, I think)
  21. Lack of early feedback
  22. No ending [to] project
  23. Not following process
  24. Conflicts (too much)
  25. Keeping Top 20 impediments
  26. Distributed team
  27. Lack of process
  28. Lack of management
  29. Communication
  30. Too many cooks
  31. Product knowledge gap
  32. Scope creep
  33. Not defining DOD
  34. Lack Buy-in
  35. Lack of process for Development Tasks
  36. Technology group (IT) support infrastructure
  37. Testing Time
  38. Bug fixing time
  39. Not having all Scrum activities
  40. Management available
  41. Lack of communication
  42. Poor planning
  43. No estimates (no velocity)

 

twittergoogle_plusredditlinkedinmail
twitterlinkedinrss
Categories: Blogs

Tennis coaching , Halo effect and celebrity bias

Agile World - Venkatesh Krishnamurthy - Thu, 04/03/2014 - 22:09

One of my friends is a very successful  tennis coach, however, he sends his kids to a different coach.  This was interesting, and I asked him why can’t he teach his kids. His response didn’t surprise me at all. He said, kids take parents for granted and some times, they listen to outsiders more intently.

I see a similar pattern at work as well.  Some times, employees listen to a highly paid external consultant rather than an in-house expert or supervisors.

Why is that ?

I googled around to find some research or articles around this kids behavior, and I found this interesting article.  The author gives the following 3 reasons behind kids behind deaf to their parents:

  • Biggest Reason #1 - You don't listen to them.
  • Biggest Reason #2 - You don't do what you say you're going to do.
  • Biggest Reason #3 - You don't keep the commitments you make.

Applying the above reasons in the context of organizations,  I see that employees don’t listen to organizations when organizations don’t listen to them. Is this a reasonable hypothesis  ?

On a similar noteI have seen another “Celebrity bias”.  I have seen some tweets from celebrities tweeted  and favorited by hundreds. But the same information published by a lesser known person does not get noticed much.  For example,  if  Seth Godin or Richard Branson say something and if a common man “X” says exactly the same thing, then people tend to believe celebrities more than a common man.

Why do we have this celebrity bias ?

Many people attribute this to  “Halo Effect” .  Some good stuff from the article below…

As you read above, the halo effect can influence how teachers treat students, but it can also impact how students perceive teachers. In one study, researchers found that when an instructor was viewed as warm and friendly, students also rated him as more attractive, appealing, and likeable.

Marketers take advantage of the halo effect to sell products and services. When a celebrity spokesperson endorses a particular item, our positive evaluations of that individual can spread to our perceptions of the product itself.

Job applicants are also likely to feel the impact of the halo effect. If a prospective employer views the applicant as attractive or likeable, they are more likely to also rate the individual as intelligent, competent, and qualified.

So, the next time you trying to make an evaluation of another person, whether it is deciding which political candidate to vote for or which movie to see on a Friday night, consider how your overall impressions of an individual might influence your evaluations of other characteristics. Does your impression of a candidate being a good public speaker lead you to feel that she is also smart, kind, and hard-working? Does thinking that a particular actor is good-looking also lead you to think that he is also a compelling actor?

Categories: Blogs

What’s Wrong With My Kanban Board?

TargetProcess - Edge of Chaos Blog - Thu, 04/03/2014 - 21:03

Having work visualized is the most obvious benefit of using Kanban boards for project management. Nothing else captures so well what a team is doing , as the work is retrieved from the hidden virtual closets of our minds (or, rather, databases), and externalized on a Kanban board. Especially if this board can be seen not only on a desktop computer but on a large wall-mounted screen. The more our office environment is saturated with all kinds of visual reminders, subtly incorporated in the surroundings, Kanban board being one of such reminders, the more likely we are to keep focus on our work and to perform better.

tv

I don’t want to keep dwelling on how great Kanban is, though. I’d rather look into some of the reasons why we at times feel that something is wrong with the electronic Kanban board. Putting it in words will help see how to tune this “digital equipment” to our particular needs.

I have soo many cards on the Kanban board.. How do I make sense of all of them?

This feeling will most likely beget companies that experience rapid growth from 10 to 20 to 50 people and beyond, and need to work with more and more cards in their Kanban boards. All is fine, until your backlog and work in progress is covered by 50-70, or 100 cards at most. Having any more cards shown on a board in a snapshot would be a no-no. The clogged board space rather hinders your work, than facilitates it. What would the solution be, then?  Your Kanban board needs to be able to zoom in/out, with the ability to collapse cards in any given state, as on the screen below:

Targetprocess 3 with many cards

I need to visualize milestones. My Kanban board does not do that :(

This could be a real showstopper. While we appreciate the visual flow that Kanban provides, we are not working in car production, like Toyota. They didn’t have this need to pay attention to time. Assembly line process goes in circles. In software production, though, projects are time-sensitive in 99% cases. It’s quite rare, if not totally utopian, for a company to operate without looking at their watch. The clock is ticking, and if a Kanban board has no way of showing “what time is it?” for a project, this could be a huge source of discomfort. Ideally, we want our Kanban both to keep looking like a board and to convey the sense of time. Like that:

Targetprocess 3 timeline view

I want my Kanban board updated real-time on any screen in the world that has it open!

This is not a crazy perk. Some companies work with several distributed teams. Even teams located in one office building and in different rooms need such live updates to track their work items real-time. If you are not looking to clear a mess with some un-synced updates (hardly you are), you will want your Kanban board to show the updates like this:

I’ve covered just 3  common cases in this write-up.  Any further look into the “what’s wrongs” will depend on what you need to see, to do your work, in your company.

Look into the peephole on the right, if you want to explore how 99% of all possible Kanban “what’s wrongs” can be successfully tackled in a visual project management tool.

Related articles:

Stuck with Kanban? Consider Multiban

Our Evolution of Visual Process Management

Kanban as Multiban?

Categories: Companies

The Stages of Agile Success

Agile Game Development - Thu, 04/03/2014 - 20:02
Achieving the full benefit of agile requires a long-term commitment to change.  Applying the basic practices, such as answering three questions for 15 minutes a day, is simple, but adopting the mindset of self-organization, continuous improvement and building a culture of engagement, trust and respect is challenging.
The Three Stages of Agile AdoptionOver the past decade, I’ve witnessed common patterns of successful agile adoption and have grouped them across three stages[1] shown below, which I call the apprentice, journeyman and mastery stages.


When speaking about agile, we're talking about the agile values and principles.  How these are embodied in your day-to-day practices depends on your culture and the framework for your process.  Scrum is one such popular framework, Kanban another.  These frameworks are great scripts for starting agile, but over time teams change the practices and even blend them.  In this article, I'll mainly use Scrum terms, but your terms may vary.
ApprenticeTeams that are newly formed and/or are new to agile aren't expected to apply agile practices very well at first.  They need constant coaching as they struggle to figure out who does what and when[2].

Apprentice teams learn how to deliver features at a regular cadence and apply new roles such as Product Owner and ScrumMaster.

I prefer to see apprentice teams follow the practices, such as those of Scrum, “by the book”, because changes at the start of Scrum adoption are usually done to conceal problems Scrum exposes.

Effective Daily Stand-ups
One example of abandoning a practice too early is when teams skip the daily stand-up meeting because they feel an electronic tool is better for reporting task status.  Reporting task status is a part of the stand-up, but it is not the primary purpose and so something is lost.  The daily stand-up is meant to align a cross-discipline team to their daily priorities, revisit their commitment to their sprint goal and recommit their accountability to delivering quality features.  Thinking that it's all about task reporting is a vestige of a task-assignment culture and it takes a while to change this mindset.

Cross-Disciplined Teams
Forming cross-discipline teams that can commit to goals is critical to early adoption.  Departmental or siloed organizations will resist the formation of cross-discipline teams.  Not only do department managers fear losing control, but developers themselves will resist being teamed with those outside their own discipline.  Yet, if cross-discipline teams don't form, then the weight of dependencies and the inability to deliver a demo-able game every iteration, will prevent most of the benefits found with agile.

Well formed cross-discipline teams can take more ownership of their goals, which leads to more effective problem-solving and higher productivity.

Established Roles
Roles, such as Product Owner and ScrumMaster, are meant to balance the need to build the right features in the right order and in the right way.  The roles are separated, because they often come into conflict with one another and need to be balanced for there is a fine boundary between building features faster through improvements to productivity and building features faster by dropping quality.

Realigning existing roles with the new ones take a while to establish and even longer for the teams to understand how they are meant to function.
JourneymanWhen agile teams create a definition of done and start altering their practices to achieve it every iteration, it's a signal that they are entering the Journeyman stage.   The following areas of development maturity are common with Journeyman teams.

Leaner Designs
Through close collaboration, Journeyman teams reduce handoffs of written design documents and concept art.  For example, instead of a dozen storyboards for a level, a concept artist will draw half as many and spend more time working directly with the level artists and designers.  In this way, all disciplines can more effectively collaborate and iterate on more emergent and higher quality levels than a one-way handoff of concept art would allow.

Faster Integrations
As cross-discipline teams iterate more, the inefficiencies of practices such as branch-and-merge and hand-testing everything are replaced by practices such as continuous integration, test servers, unit testing, etc.  These practices allow more iterations on up-to-date assets and code throughout the day.  The ability to iterate more frequently contributes to higher quality.

Better Testing
As mentioned above, faster integration requires improved testing practices, such as test servers.  Additionally, Journeyman teams will increasingly integrate members of QA onto their team.  This will lead to further refinements of the definition of done.

Release Planning
As journeyman teams improve their definition of done, agile estimation techniques can be employed to produce a more reliable forecast about the schedule, cost and scope.
MasteryMastery is a stage occupied by so-called hyper-productive teams.  These teams hold themselves accountable to their results, practices and organization.  For teams to enter this stage, they must have an established level of trust within the organization and be allowed to achieve higher levels of self-organization.

100% Customization
Sometimes, when I visit a team that has been effectively inspecting and adapting agile and Scrum practices for a while, it’s hard to say “they're doing Scrum” anymore.  They completely own their work, and take much pride in it.

Self-organization
The goal of Scrum is to leverage the power of small, self-organizing teams to maximize the value they create.  By giving teams and individuals more freedom to make decisions about their work and providing structure, coaching and mentoring, their work becomes far more focused and meaningful.

Studio culture and structure are often barriers to this “low constraint” form of self-organization.  Fortunately, as more studios emerge that demonstrate the value of this approach, the acceptance and proof of it will continue to grow.

Continuous Improvement
Following a set of prescribed practices isn’t the goal.  The goal is continuous improvement.  Markets and technologies change.  Individuals change.  Processes have to change as well.  There are no "best practices" because the word "best" implies that there are no better.
It's Not Easy, but it's RewardingThe agile state of mind challenges our beliefs and assumption and insists that we continue to challenge them.  It flat-out defies the persistent superstition that we can treat creative people with the same tools that make machinery more productive, that we can add more people or add more hours they work or write bigger planning documents, which will result in more output.  People are far more complex.

It makes us coach, listen, challenge, inspire, care, respect, and collaborate in ways we were never trained to do.  It's a lifetime challenge with no finish line in sight.


[1] These are not unlike the three stages of martial art mastery called “ShuHaRi”
[2] This is not inherent to Scrum teams, all new teams go through a settling phase.  Google “Tuckman’s stages of group development” for more on this.

Categories: Blogs

Announcing Summer of Scrum Toronto 2014 Pre-Registration

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

One of our big plans this summer is to have a selection of advanced Scrum and Agile – related training courses.  We are delivering some of them ourselves, but we are also bring in outside experts for others.

Here is the course list at a high level:

- a 1-day “Advanced ScrumMaster” course
- a 1-day “Advanced Product Owner” course
- a 1-day “Managing for Success” course
- a 1-day “Enterprise Agile” course
- a 2-day “Agile Engineering Practices” course
- a 2-day “Agile Coach Training” course

Our schedule for these events will be finalized in the next few weeks.  If you are interested in any of these courses, please pre-register here.  Pre-registration will give you a guaranteed spot and a discount of 10% above and beyond the early-bird registration price.

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

Agile Development Conference, Las Vegas, USA, June 1–6, 2014

Scrum Expert - Thu, 04/03/2014 - 17:51
The Agile Development Conference is an event focused on agile methods, technologies, tools, and leadership principles from thought leaders that takes place in Las Vegas. You will find at this conference inspiring keynotes, in-depth tutorials and a wide range of conference sessions. Famous Agile speakers will participate to the conference like Johanna Rothman, Ellen Gottesdiener, Janet Gregory, Pollyanna Pixton , Al Shalloway and Mitch Lacey. In the agenda up you can find topics like “The Organization Must Change Before Going Agile”, “Patterns for Effective Use Cases: Unleashing Your System’s Value”, “Essential Agile ...
Categories: Communities

Who Solves Which Problems?

Johanna Rothman - Thu, 04/03/2014 - 17:37

Many years ago, I was part of a task force to “standardize” project management at an organization. I suggested we gather some data to see what kinds of projects the client had.

They had short projects, where it was clear what they had to do: 1-3 week projects where 2-4 people could run with the requirements and finish them. They had some of what they called “medium-risk, medium return” projects, where a team or two of people needed anywhere from 3-9 months to work on features that were pretty well defined. But they still needed product managers to keep working with the teams. And, they had the “oh-my-goodness, bet the company” projects and programs. Sometimes, they started with a small team of 2-5 people to do a proof-of-concept for these projects/programs. Then, they staffed those projects or programs with almost everyone. (BTW, this is one of the reasons I wrote Manage It! Your Guide to Modern, Pragmatic Project Management. Because one size approach to each project does not fit all!)

The management team wanted us, the task force, to standardize on one project management approach.

In the face of the data, they relented and agreed it didn’t make sense to standardize.

It made a little sense to have some guidelines for some project governance, although I didn’t buy that. I’ve always preferred deliverable-based milestones and iterative planning. When you do that, when you see project progress in the form of demos and deliverables, you don’t need as much governance.

There are some things that might make sense for a team to standardize on—those are often called team norms. I’m all in favor of team norms. They include what “done” means. I bet you’re in favor of them, too!

But, when someone else tells you what a standard for your work has to be? How does that feel to you?

I don’t mind constraints. Many of us live with schedule constraints. We live with budget constraints. We live with release criteria. In regulated industries, we have a whole set of regulatory constraints. No problem. But how to do the work? I’m in favor of the teams deciding how to do their own work.

That’s the topic of this month’s management myth, Management Myth 28: I Can Standardize How Other People Work.

If you think you should tell other people how to do their work, ask yourself why. What problem are you trying to solve? Is there another way you could solve that problem? What outcome do you desire?

In general, it’s a really good idea for the people who have the problem to solve the problem. As long as they know it’s a problem.

How about you tell the team the outcome you desire, and you let them decide how to do their work?

Categories: Blogs

Agile Inception: Facilitating Innovation Towards Valuable Results

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

I recently had the opportunity to help facilitate a client’s “Innovation Challenge”.  Basically, the concept is to get a bunch of people in the room, give them a business challenge and see what they come up with.

I have to say that the format of the workshop that I used is heavily inspired by a training that I did recently called Specification By Example by Gojko Adzic.  I strongly recommend this seminar as well as the book.  Another strong influence is The Inmates are Running the Asylum… by Alan Cooper.  The workshop that I have developed is a sort of hybrid approach, with my own flavour added to the mix.  During an early iteration of the workshop, I didn’t have a title and one of the participants suggested “Agile Inception”.  I think that title works in a space where Agile is established and well understood (e.g. hopefully this blog).  At the same time, this workshop can be run with people who have no prior experience or knowledge of Agile and without even mentioning the word Agile.  This is also good in certain environments where people have developed an Agile allergy.

Anyhow, my goal for the day was to facilitate the building of shared understanding of the challenge itself as well as some ways that the organization could innovate around that challenge through conversation and collaboration.

From the opening remarks it became clear that the product at the centre of the “challenge” was actually in deep crisis:  a shrinking market combined with shrinking market share.  The product had generated approximately $18M in revenue in 2009, compared with $10.4M projected for 2014.  That’s half dead in some people’s books.  The clear Goal was to reverse that trend, starting with at least $11M in 2015.  They needed a powerful jolt of life-giving innovation energy to defibrillate their failing product’s heart.

There were no shortage of ideas about how the product could become better & more profitable.  In fact, there were many, many ideas.  Too many, perhaps.  Once we had established our working agreement for the day, we did a Starfish Retrospective exercise to make visible all of the things that the group wanted to keep doing, start doing, stop doing, do more of and do less of.  Many post-it notes were stuck on the board and we left them there as a reminder of all of the things that people were thinking about that could help us to consider how the product and ways of working on it could be improved.

Then we talked about the Goal.  True innovation—that is, tangible, innovative results with clear benefits—requires a group to focus on a single, clear, SMART (Specific, Measurable, Achievable, Relevant and Time-bound) Goal that everyone in the organization understands and is committed to achieving.  Often times, as was the case with the group on Thursday, taking time to establish shared understanding of the goal can seem redundant and tedious (“we already know what the goal is…”).  However, as we learned through the process of working in small groups to re-articulate understanding of the Goal back to the “customer” (the person paying for everyone to be there) this often requires some further conversation.  Indeed, when the groups presented their understanding of the Goal, there were gaps that needed to be filled by the “customer”.  It took less than 30 minutes to discuss, adapt and confirm the Goal with the customer.  The value of this investment of everyone’s time was tremendous.  The conversation made it clear that shared understanding had already been established to a degree and enabled the group to build on what was already there to make the Goal “SMARTer” in the minds of all of the participants.

A single, transparent business Goal helps us to innovate with focus—to create the right thing.  In addition, we need to develop a single Persona—the ideal, “imaginary” user of the product.  The larger group broke into smaller groups for the subsequent discussions.  The groups worked separately and generated a the details for a few personas.  All 3 personas added value to the conversation.  The Persona of “Lisa” was particularly compelling to the “customer” because she had a clear goal of her own and through innovation, her goal could be aligned with the overall business Goal to create a powerful, “new” product that just might reverse the downward trend.

The next step in innovating with focus in order to generate the best ideas possible: build shared understanding of how Lisa can pursue her goal through her experience of the product in order for the business Goal to be achieved.  In other words, Lisa needs a story.  Her story needs a beginning and an end (for now, until the next story) and all the stages of her journey need to be integrated into a coherent whole.

The last step was for the groups to brainstorm and come up with different ways that the product can deliver Lisa’s story in order to realize the Goal.

I wish I could say more about the really cool ideas that the group came up with, but I am erring on the side of caution when it comes to protecting my client’s competitive advantage.

To wrap up the session, we took a quick, anonymous gauge of how confident the participants felt about achieving the Goal.  Of the 13 participants, two gave their confidence a score of 8/10, six gave a score of 7/10, four scored themselves a 6/10 and one was a 3/10, for an average of 6.5/10.  Not bad, but clearly some work still to go.  So what’s next for them?

Next steps:
  • Get the technical folks involved in the conversation (ideally, they are there from the beginning)
  • Build an increment of their solution
  • Review
  • Continue the conversation and collaboration to build shared understanding 
  • Re-gauge the confidence score
  • Iterate  
  • Repeat 
  • The likelihood of achieving the Goal increases with every iteration

 

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

Using AutoMapper to prevent SELECT N+1 problems

Jimmy Bogard - Thu, 04/03/2014 - 15:13

Back in my post about efficient querying with AutoMapper, LINQ and future queries, one piece I glossed over was how View Models and LINQ projection can prevent SELECT N+1 problems. In the original controller action, I had code like this:

public ActionResult Index(int? id, int? courseID)
{
    var viewModel = new InstructorIndexData();
 
    viewModel.Instructors = db.Instructors
        .Include(i => i.OfficeAssignment)
        .Include(i => i.Courses.Select(c => c.Department))
        .OrderBy(i => i.LastName);
 
    if (id != null)
    {
        ViewBag.InstructorID = id.Value;
        viewModel.Courses = viewModel.Instructors.Where(
            i => i.ID == id.Value).Single().Courses;
    }
 
    if (courseID != null)
    {
        ViewBag.CourseID = courseID.Value;
        viewModel.Enrollments = viewModel.Courses.Where(
            x => x.CourseID == courseID).Single().Enrollments;
    }
 
    return View(viewModel);
}

See that “Include” part? That’s because the view shows information from navigation and collection properties on my Instructor model:

public class Instructor : Person
{
    [DataType(DataType.Date)]
    [DisplayFormat(DataFormatString = "{0:yyyy-MM-dd}", ApplyFormatInEditMode = true)]
    [Display(Name = "Hire Date")]
    public DateTime HireDate { get; set; }

    public virtual ICollection<CourseInstructor> Courses { get; set; }
    public virtual OfficeAssignment OfficeAssignment { get; set; }
}

public abstract class Person
{
    public int ID { get; set; }

    [Required]
    [StringLength(50)]
    [Display(Name = "Last Name")]
    public string LastName { get; set; }
    [Required]
    [StringLength(50, ErrorMessage = "First name cannot be longer than 50 characters.")]
    [Column("FirstName")]
    [Display(Name = "First Name")]
    public string FirstMidName { get; set; }

    [Display(Name = "Full Name")]
    public string FullName
    {
        get
        {
            return LastName + ", " + FirstMidName;
        }
    }
}

If I just use properties on the Instructor/Person table, only one query is needed. However, if my view happens to use other information on different tables, additional queries are needed. If I’m looping through a collection association, I could potentially have a query issued for each loop iteration. Probably not what was expected!

ORMs let us address this by eagerly fetching associations, via JOINs. In EF this can be done via the “Include” method on a LINQ query. In NHibernate, this can be done via Fetch (depending on the query API you use). This is addresses the symptom, but is not a good long-term solution.

Because our domain model exposes all data available, it’s easy to just show extra information on a view without batting an eye. However, unless we keep a database profiler open at all times, it’s not obvious to me as a developer that a given association will result in a new query. This is where AutoMapper’s LINQ projections come into play. First, we have a View Model that contains only the data we wish to show on the screen, and nothing more:

public class InstructorIndexData
{
    public IEnumerable<InstructorModel> Instructors { get; set; }

    public class InstructorModel
    {
        public int ID { get; set; }

        [Display(Name = "Last Name")]
        public string LastName { get; set; }
            
        [Display(Name = "First Name")]
        public string FirstMidName { get; set; }

        [DisplayFormat(DataFormatString = "{0:yyyy-MM-dd}", ApplyFormatInEditMode = true)]
        [Display(Name = "Hire Date")]
        public DateTime HireDate { get; set; }

        public string OfficeAssignmentLocation { get; set; }

        public IEnumerable<InstructorCourseModel> Courses { get; set; } 
    }

    public class InstructorCourseModel
    {
        public int CourseID { get; set; }
        public string Title { get; set; }
    }
}

At this point, if we used AutoMapper’s normal Map method, we could still potentially have SELECT N+1 problems. Instead, we’ll use the LINQ projection capabilities of AutoMapper :

var viewModel = new InstructorIndexData();
 
viewModel.Instructors = db.Instructors
    .OrderBy(i => i.LastName)
    .Project().To<InstructorIndexData.InstructorModel>()
;
 

Which results in exactly one query to fetch all Instructor information, using LEFT JOINs to pull in various associations. So how does this work? The LINQ projection is quite simple – it merely looks at the destination type to build out the Select portion of a query. Here’s the equivalent LINQ query:

from i in db.Instructors
orderby i.LastName
select new InstructorIndexData.InstructorModel
{
    ID = i.ID,
    FirstMidName = i.FirstMidName,
    LastName = i.LastName,
    HireDate = i.HireDate,
    OfficeAssignmentLocation = i.OfficeAssignment.Location,
    Courses = i.Courses.Select(c => new InstructorIndexData.InstructorCourseModel
    {
        CourseID = c.CourseID,
        Title = c.Title
    }).ToList()
};

Since Entity Framework recognizes our SELECT projection and can automatically build the JOINs based on the data we include, we don’t have to do anything to Include any navigation or collection properties in our SQL query – they’re automatically included!

With AutoMapper’s LINQ projection capabilities, we eliminate any possibility of lazy loading or SELECT N+1 problems in the future. That, I think, is awesome.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Categories: Blogs

Episode #135 – Ticket Driven Agile

Integrum - Agile Weekly Podcast - Thu, 04/03/2014 - 15:00

Derek Neighbors, Jade Meskill, Clayton Lengel-Zigich, and Jake Plains discuss:

  • Ticket Driven Agile
  • Cross team collaboration
Email
Categories: Companies

Querying An In-Memory Array Of JavaScript Objects In NodeJS

Derick Bailey - new ThoughtStream - Thu, 04/03/2014 - 13:00

I found myself wanting to query an array of in-memory objects in my NodeJS app. I know there are a ton of options out there… including the built-in filter method on arrays, underscore or lodash where methods, and more. But I really wanted something that worked like MongoDB queries. 

What I Want To Do

Given this data structure:

I wanted to write a query that looked something like this:

sift.js: How I Got What I Wanted

What I found (thanks to Joe Gornick) is sift.jsa MongoDB inspired query library for JavaScript arrays.

It’s pretty slick. It let’s me write and execute the above query, running it against my array of objects:

This returns the second object, as I expected.

Lots Of Options

From the documentation, it looks like it should work in browsers as well as nodejs environments. Of course, this all makes me wonder if MongoDB could create a portable version of their query library to use in NodeJS… but I’m liking sift so far. It does what I want, and seems small / simple enough.

I’m sure there are plenty of ways to achieve close-to this syntax with other libraries like underscore / lodash, or other JSON / JS query libraries, too. I picked sift because I like that it models after MongoDB queries. I’m already familiar with that syntax, and I’ll be able to take advantage of it as I need more complex queries.

     Related Stories 
Categories: Blogs

Physical Taskboards

Growing Agile - Thu, 04/03/2014 - 10:00

You’ve decided to create a physical task board for your team. Great! Now the question, what materials are best? White boards, pin boards, sticky notes? I’ve used a range in my time as an agilist, here are my thoughts.

Taskboard Physical Taskboards

Whiteboards

Most teams who have been doing agile for a while with physical boards end up with whiteboards. These can look pretty professional, and have the benefit of being able to draw on them as well.

Some tips to consider if you plan to use a whiteboard.

Prestick and sticky notes don’t stick well to whiteboards, and they end up leaving marks on the board. It’s better (if more expensive) to invest in a magnetic whiteboard and either lot of magnets, or in magnetic task cards. You can buy flexible magnetic vinyl sheets that are erasable like a whiteboard, and cut it up to make task sized cards. It does mean you need to erase the cards each sprint, if you’d prefer not to, just get a bunch of small magnets and then use non-sticky paper (like note cubes) for tasks.

Lots of people use vinyl tape to create lines on their magnetic whiteboards. This is great until you decide to change your columns. The tape ends up marking the boards. A simpler solution is just to draw the lines in a permanent marker, that way they won’t get erased. When you want to move the lines, simply trace over the permanent marker with a whiteboard pen, and magically it erases icon smile Physical Taskboards

Another thing to consider is getting the whiteboard on wheels, that way you can take your task board into meetings like sprint planning. Personally I find it a bit clunky, and I’d rather have more space by mounting the whiteboard on a wall.

Finally remember to have enough room around your whiteboard for a standup. Lots of people have then on walls between 2 desks, or passage ways and then people struggle to all stand at the board for the daily scrum.

Pin boards

A cheaper alternative to whiteboards is a pin board. Again post-it notes don’t stick well, so you need note cards and lots of pushpins. A tip, make sure the pins you get are easy to use with a plastic head, rather than flat metal drawing pins and that the board is not too hard. I have seen many team members curse with sore fingers from bad pin boards/pins. String is great to use to create lines on a pin board.

A problem I’ve seen with pin boards is that if tasks move around a lot, then the task cards can get a little ragged. A bit of tape over the top where they get pinned can solve this.

One benefit for pin boards is that if you use a tool as well as a physical board, you can print your story cards.

As with whiteboards decide if you want the pinboard to be portable or not. These are definitely a bit easier to make portable than whiteboards, especially if you get a fairly small pinboard. If that’s important to you, this might be a better option.

Walls and Windows

If ordering a whiteboard or pinboard takes 4 weeks of procurement and forms in triplicate, consider just using a wall or window. Masking tape is perfect to create lines, and you can stick stuff to the walls with prestik. Note the prestik will mark the walls and potentially pull off paint, so be sure that’s okay with the office police first icon smile Physical Taskboards Again post-it notes don’t stick to walls well, although they stick fantastically to glass, so if you have a window instead of a wall, post-it notes are great.

A simple alternative that we use a lot is just a piece of flipchart paper stuck to the wall with masking tape, then stick the post it notes on to the paper. It works great, and it has the benefits of being easily portable. This is  the option we use the most at Growing Agile, check out what our office walls look like.

walls Physical Taskboards

 

Categories: Companies

Peter Drucker on Knowledge Worker Productivity

Agile & Business - Joseph Little - Thu, 04/03/2014 - 05:31

In the Winter of 1999, Peter Drucker had published an article on Knowledge Worker Productivity: The biggest challenge.  Here is access to the article.

Here is the second sentence: “The most important contribution management needs to make in the 21st century is similarly to increase the productivity of knowledge work and knowledge workers.”

Here is a quote from some key ideas in the article:

Six major factors determine knowledge-worker productivity.
▪ Knowledge-worker productivity demands that we ask the question: “What is the task?”

▪ It demands that we impose the responsibility for their productivity on the individual knowledge workers themselves. Knowledge Workers have to manage themselves. They have to have autonomy.
▪ Continuing innovation has to be part of the work, the task and the responsibility of knowledge workers.
▪ Knowledge work requires continuous learning on the part of the knowledge worker, but equally continuous teaching on the part of the knowledge worker.
▪ Productivity of the knowledge worker is not—at least not primarily—a matter of the quantity of output. Quality is at least as important.
▪ Finally, knowledge-worker productivity requires that the knowledge worker is both seen and treated as an “asset” rather than a ”cost.” It requires that knowledge workers want to work for the organization in preference to all other opportunities.

Very interesting ideas.

twittergoogle_plusredditlinkedinmail
twitterlinkedinrss
Categories: Blogs

Setting Expectations

George Dinwiddie’s blog - Thu, 04/03/2014 - 03:50

Karl Scotland wrote an excellent blog post on Estimates as Sensors. In it, he extols the use of estimates to “sense capability and create feedback for yourself.” This is similar to my point in Estimation as Hypothesis.

At the end of this post, it now says “I don’t recommend using them to make promises and give guarantees to others.” Originally, this said something like “I don’t recommend using them to make promises and setting expectations of others.” I asked him what he did use for setting expectations. He had two responses. “I’d say expectations are set from understanding our capability, refined through sensing, and with a confidence range.” and changing the post to reflect his original intent.

There’s more to this business of setting expectations.

First of all, when we uses sensing estimates to understand our capability, we’re setting our own expectations. We can be pretty ignorant of those capabilities if we’re not paying attention. And, as software developers, we’re usually paying attention to myriad other details rather than our own capability. I know I do.

Years ago, I had a project lead who asked me to estimate how long it would take to fix a reported bug in some code written by a colleague who’d since moved to a different project. I looked at the bug report and made a list of the changes I would have to make. Then I estimated how long it would take to edit, compile, and verify each of those changes. I handed this annotated list to the project lead. He took one look at it and said, “You can’t do any task in 10 minutes. It will take you longer than that to checkout the code, find the place to change, and check it in again. Never estimate a programming task at under 30 minutes.” That’s when I realized that I was only estimating part of the required work, the programming part on which I was focused, not the necessary parts that enabled the programming.

I’m pretty terrible at tracking my own capacity as an individual. Not only do I tend toward a narrow focus that excludes that, but I forget to track interruptions. An interruption already gives me two things to think about at once, but tracking it would be a third. That’s a lot for one brain. I do better when I’m part of a team. The nature of team work allows me opportunities to pop up to a larger viewpoint more easily. And within a team that’s worthy of the name, it’s easy to be honest about both the capability and the uncertainty concerning it.

Even as we gain a better understanding of our own capacity, how do we set appropriate expectations for others? This is the crux of many estimation conundrums. Most developers are used to low trust relationships with those asking for estimates. They’ve been burned in the past with estimates being treated as guarantees, with estimates being treated as initial positions for negotiations, with estimates being accepted without the conditions assumed for the estimates. Who hasn’t estimated how long some task would take and then be given another task to do in the same time?

If we know how our estimates are going to be treated, we can apply “fudge factors” or “Kentucky windage” to compensate. If we know our manager is going to cut our estimate in half, we may double the number we offer. Knowing that our estimate is going to be treated as a commitment, we may pad it for contingencies. Knowing that we’re going to be subjected to interruptions, we may extend it based on interruptions in the past. How much we pad depends on whether our estimate is expected to be at the 100%, 99%, 90% 80%, or 50% confidence level.

In fact, the padding tends to go up radically the higher the expectation for the estimate. These two measurements are also related to the consequences for missing it. When someone expects an estimate at the 100% confidence level, they’re outside the realm of the natural world. There is always the possibility of something completely unpredictable, a “black swan” in Taleb’s terminology. With that unreasonable level of expectation, people often couple it with a sense that if something does go wrong, someone should be punished. There’s no allowance for things outside of someone’s control.

There is always some things we don’t know, and some of those are things we don’t know we don’t know. A friend once devised Hughes Law: “On any boat maintenance project, there will be at least three unforeseen complications, at least one of which will follow this law.” He recommended taking your estimated time for the work, tripling the number, and incrementing the unit of time measurement. That two day job becomes 6 weeks. When we have an extreme level of uncertainty, then giving any number can make us nervous.

What if we were able to set expectations beyond a simple number? What if we could say what we know and what we don’t know? What if we could give our best estimate now, and give a better one next week when we know more? Would that help?

The thing is, these questions are not about the estimates. These questions are about the relationship between the person estimating and the person using the estimate. How can we improve that relationship?

Categories: Blogs

Define Your Agile Transformation

Rally Agile Blog - Wed, 04/02/2014 - 19:56

At last year’s Technology & Innovation -- the Future of Banking & Financial Services conference in Sydney, Australia, senior executives repeatedly used the following keywords (even, at times, trying to outdo each other with them):

  • customer-first
  • agility  
  • transformation
Customer-first

The first keyword is easy to understand and confirms something we know, but often overlook: we need to be more “customer-aware” and listen to customers’ needs and wants, rather than assuming that we already know what these are.

Here's a good example of what it means to be customer-first: at the TUANZ (telecommunications forum) conference in New Zealand several years ago, three telcos made presentations. The first two went up to the podium and showcased their new glitzy, glamorous products, only to face a barrage of questions from the audience about their seemingly less important products and features. The third presenter took the stage with a simple message: “This is what you’ve been asking us for -- and this is how we’ve delivered it.”  

You can guess which company received the most applause and enjoyed greater business opportunities. This simple message really resonated with me and has defined my approach to business ever since.

Agility

The second keyword, “agility,” is more ambiguous. What do senior decision-makers really mean by agility?

It doesn’t require poetic licence to interpret agility as adopting Agile concepts -- such as the ability to work efficiently with minimal waste; delivering in shorter, faster cycles; divesting the big, overarching programs to smaller, value-focused initiatives; focusing on a collaborative, transparent culture; and being able to change and adapt swiftly to meet changing market conditions or a customer needs.

(I hope I'm right in interpreting the executives' message.)

Transformation

But what about the third keyword: “transformation”? At the Technology & Innovation conference, it was disappointing that no-one questioned what this term actually means. In my experience and from discussions with customers, there are two very different interpretations for the word transformation, used in this context:

  1. Optimising the IT department to deliver maximum value whilst focusing on quality and throughput (the major “continuous delivery” initiative recently announced by Australian telecommunications provider, Telstra, is a good example of this)
  2. “Organisational transformation,” where organisations look beyond IT to fundamentally changing the very way they’re structured

As an Agile practitioner and coach, I see Agile as a set of tools and concepts we can use to deliver fantastic solutions and enhance our customers’ experience. This does not mean Agile is solely focused on the IT or engineering department: in fact, I would love to see the words “IT department” pushed to file 13 and hear more talk about the business delivery teams. After all, isn’t that why we’re here?

In most cases, when an executive is talking about transformation he or she actually means they want to optimise the manner in which IT work is flowed through their delivery systems. Hence the focus on scaling Agile, continuous delivery, and creating “Scrum teams.” There’s nothing wrong with this approach and indeed it is a necessary step along the path.

The bigger definition of transformation, however, delivers significantly greater value and has a far more wide-reaching scope. It includes bringing agility to areas such as legal, finance, HR, operations, real estate, and the executive suite.

Where Are You?

To deliver the greatest value from our delivery systems we need to look at all the pieces of the puzzle. Here are some questions to ask yourself in figuring out where you fall on the transformation path:

  • Do your funding regulations and approaches align with an Agile way of working?
  • Do you hire managers, leaders, developers and other personnel with the personality traits to support an Agile delivery approach?
  • Are your operations teams involved up-front and continuously throughout the delivery cycle, or are they the forgotten teams at the bottom of the cliff, where you push off a solution to the public and expect them to support it?
  • When it comes to real estate, are your office spaces fitted out to support a transparent and collaborative culture?
  • Are your executives trained to personally champion and lead an Agile approach?
  • Do the people who interact with your organisation’s customers understand the streamlined delivery approach of Agile, and align their work requests, funding, support, and communications strategies with this approach? In other words, are they part of your delivery team?

Now that you've thought about these questions, where do you come out on the transformation continuum? I would hazard a guess that some of these questions were hard for you to answer: you wanted to say “Yes” but if you were totally honest, your answer would probably be a “No.” If that’s true for you, then consider this an opportunity to start a discussion around how to really transform your business and delivery activities with a well-structured and disciplined delivery approach.

We do so many things right; yet the drag of the past, fear of risk, and loss of control is a millstone around the neck of progress. You can transform into an organisation that delivers customer-first products and services, to great applause and business success; and the path to your transformation begins with agility.

Get in touch with Steve, or find out more about Rally’s Transformation Services.

Steve Lawrence
Categories: Companies

Knowledge Sharing


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