Let’s say You have just finished to create the user stories for your product and, a bit proudly, your product backlog now counts two or three hundred of items. How can you estimate them, effectively? It is not always possibile to have all the items of the backlog estimated using the planning poker game. This [...]

I remember how eager I was earlier this year to hear what Phil, the prophetic groundhog, predicts about spring. There’s a special reason for that: as the name of my post suggests, it had to be published not before we felt something close to what it actually is about — joy spring!  Not even that much surprising, but Phil’s prediction turned out an epic fail, as spring got delayed beyond any reasonable standards. Finally, about 2 weeks ago, spring remembered about us, the freezing folks. Even Phil, the Groundhog, screwed up with his estimate, and while the spring is already far in, it’s high time to come up with a very fitting narrative of what missed deadlines, and deadlines in general, are about.

Apart from spring itself, there’s actually one more reason for joy. We’ve finally come up with TargetProcess 2.24, the spring 2013 release. The keyword is “finally”. We were supposed to be done with it much earlier. But it appears the release wouldn’t want to venture into the outer world in any other weather than the spring one (thank you, Phil).

Enter Deadline (escorted by Estimate)

Jokes aside, I wouldn’t be mistaken if I said that many meetings in software development are supposed to dissect the reasons for missed deadlines, or delivering later than expected.  I’ve been interested in studying the metaphysics of deadlines for quite a while (see my earlier post, it dates back to 2009). Now, if deadlines are in the spotlight of most meetings, which typical questions are supposed to be answered? And, what’s more important: even with answers to these questions in place, are we getting down to the roots of the real business “pain”?

Some of those questions would be: Why are we late? Why were our estimates bad? Maybe someone under-performed? The sacred holy deadline has everyone dancing before its altar like puppets on the strings.  It isn’t unfamiliar for people to have this nagging feeling as they come to a meeting and expect that someone’s head is about to be cut now. Especially if there’s the rhetoric of guilt and who’s-to-blame. It’s natural (I’d say that it’s unnatural) to assume that a missed deadline means we should chase and track down the bad performers.  As this subdued air of someone’s guilt or bad performance takes lead, and people focus on the “why bad estimates” part, you can throw the time that you’re spending at this meeting to a waste bin.

Usually deadlines are tied to estimates, like addicts to abusive substances. There’s no deadline without an estimate. If you’ve spent 3-5+ years as a project manager or a product owner or a Scrum master, or as anyone else who relies on the estimates of completion, you’d know that softdev work  can not be measured and predicted due to its very its own nature, at times even with no acceptable leeway margin. Ron Jeffries has summarized this rarely outspoken truth very well in this post (actually though, there’s quite some talk about the delusion of estimates at this  time).

Stunning. It appears one cannot rely on estimates, and can’t set a deadline, or predict a release date. With stakeholders, or marketing people, or clients wanting  you to commit to a time, this seems like an extreme nonplus. How do we go about it, and how do we persuade those stakeholders that life without deadlines is not only stress-free, but it actually means a better quality software at the end?

I think that this whole concept of deadlines is built on fear and insecurity. Something very old-fashioned and 19th centiry-ish. Okay, now if we have a deadline as a whip, our horses will exhaust themselves to get the carriage out of the mud and will deliver on time.  That’s a bit of an exaggerated comparison, but what else can come to mind if people are pushed to do something faster and to stretch their limits AND for no valid reason. Well, the reason appears to be very valid. His Majesty Deadline. If we miss it, then the Earth will sure stop turning, the sky will fall down on the sun, and the seas will dry out.

Deadlines have been inherited from the distorted ways of the 19-20th century fit for manual work. They’ve been dragging along like heavy but unnoticed shackles on our feet for 20-30-40 years (depends on where we start the countdown for the onset of knowledge work industries). Somehow the pedestal on which they have been sitting seemed steady like a rock, and it never or rarely occurred to people that deadlines are actually a mess. Or, a cautious tinge of a thought like “is that all a huge scam?”  would have meant going so much against the mainstream of  established outdated ways, that rarely did anyone dare speak up.

I’ve always been uncomfortable about the concept of chasing and being in a hurry to release. Ironically, if a release has been pushed against a deadline, and the horses have been whipped, funny thing, but it did become a sure sign for me that the harder the push, the less far off is the actual release date. That’s usually the case with what I call “subjective” deadlines.

Subjective and Objective Deadlines

Deadlines as a biological species in corporate environment can be broken into 2 subspecies: subjective and objective. The universal law that I’ve derived has it that about 90% of subjective deadlines can be turned into having no deadline at all. As for the objective deadlines, it’s harder to tame them, but there’s still a way.

A deadline is subjective:

1. For a small product dev company: there’s an emotional desire to come up with a new release faster for the sake of just faster. Usually, this is something that a stakeholder wants to do because he/she believes that this release needs to be out ASAP, or the company will  sink into the financial abyss, or the competitors will come up with the same thing that very day. Or — the real classics — the production guys have estimated that the release can be expected at a certain time, and marketing has made it public as the official release date.
2. For a softdev service company: usually service companies deal with the 2nd tier of subjectivity in deadlines. It all very much depends on their customers, and since how long have the customers been working with this company, and the bottom line: how much trust do the service company and the customers have in each other. This same situation also occurs in huge product dev companies, when marketing stakeholders plan rigid timeframes for marketing campaigns and activities, and devs are not involved in that. That’s the case of disconnect, and every party has to balance their needs and reality.

The objective deadline is this:

1. Something huge.  The Russians are now busy building the infrastructure facilities  for the upcoming 2014 Winter Olympics in Sochi. This IS a deadline. It can not be missed, and the Olympics construction projects can well be treated with the same intensity as the operations of the military.
2. The next possible instance is a grave event threatening the lives and well-being of people. Like, to rescue people from the flood that can wipe away their homes or from other natural disasters, or any other events like that (well, we’re very much into the movie crap of being immersed into all kinds of bad things, like saving the planet just on time before the aliens launch their rocket etc. so I’d let your imagination conjure up any other instances like this).

This is it. Just think about it. The majority of deadlines are subjective man-made disasters. Someone has said that human side comes a long way before software is made, and deadlines are not about the technical side but about people’s nature mostly. What I’m doing right now is breaking into the sacred sanctuary of “this-is-technical-you-know-nothing-about it” stuff with my liberal arts/humanities white gloves on, and graciously pulling all kinds of nasty misjudgments about software project management out of their holes.

No Deadlines?

My conclusion is striking. We tend to think that problems with deadlines have to deal with the technical issues and technical competence, and meekly mumble about who’s done/not done what as we look for justifications, but that’s not true. Once you’re in the environment of professionals, good rooted into the team, with good contextual AND open personal relations, then the problems float into the realm of how people make their point to each other and how they adjust to each other’s idiosyncrasies. For example, it’s beyond my understanding how endlessly can designers mull over a tiny UI element. To me it makes no difference. In their turn, designers or developers wouldn’t understand how I’m messing around an error message in the product UI. Or a piece of micro-copy. There’s no reason to be mad about it. In a way, we’re aliens to each other, and we can’t go any different than by finding a common language to share and understand our idiosyncrasies. Let alone the idiosyncrasies about design and copy, the most unpredictable part is software. You never know when you can stumble upon an unexpected impediment, ask any developer. Sure thing, it would be stupid to rush the developers knowing that they are competent, and they are working on the problem. This observation relates mostly to emotional deadlines, and is about the silent reciprocal understanding of why we get stuck on our way to the golden release date.

It’s nothing else than the issue of relationships and unity in an organization, to have marketing adjust to the reality of fuzzy estimates and deadlines. Looking at many companies, and at their release dates, I’ve noticed an interesting trend. Major releases usually appear either in spring, or by early fall. That’s quite logical: winter is winter, with its Christmas time,  the late fall is Thanksgiving, summer is the time when people go on vacation. This means, one can assume that late February-mid-March are expected release dates, but silently allow the possibility that it would really be mid-April-beginning of May. Or, for the fall releases, make it mid-August but really count on mid-September-October.

As much as I’m an opponent of  “to do’s”, it appears I can finally commit to the one imperative how-to: Never push people with “when” unless it’s a matter of life and death. Only hearing this question might make them feel nervous (read, distracted from work and performing worse). It’s because of the ever-dragging legacy of the old-school insecurities, the clash of the need to give estimates and not being sure exactly of what is to be estimated, and the subsequent threat of being labelled as someone non-delivering to their expectations.

One of the things that can help with such questions and managers, though, should you encounter them in your life, is the intelligent “get done” forecasting. As in this report.

You can take these percentage probability forecasts, and show them to whoever needs an estimate of completion. If you’re curious, that’s one of the reports that we did in the recent 2.24 release. It can even work for service companies, if they have done the bulk of the enlightenment work about the fallacy of deadlines with their customers.

It might be hard to comprehend but unless we all become the beacons of the new no-deadline culture, we’d remain stuck in the outdated manual labor thinking amidst the technological progress of the 21st century. Take a look at this link. It’s a well-known Q/A resource for project managers. All of the questions tagged “deadline”, they have nothing to do with technical failures. Rather, people are not sure how should they manage communications and resolve organizational issues. Software development is more about humans as ever, since it’s getting still harder to live with no ecosystem of understanding and cooperation to replace the split reality of deadlines.

I’m still chugging along, making great progress. I took some interruptions yesterday, as many people do. They are not reflected on my kanban. They are in my calendar, which I am not showing you :-)

A potential client emailed, asked for a call. I said yes, and we arranged for a call that day. Could I have put it on my kanban? Yes. Did I bother? No. Does that make me a bad person? No. It’s my kanban, not yours.

I don’t track metrics from my kanban. If I did, I would want that and the other calls there. But I don’t, so it’s fine.

I’m using my kanban to help me to get to done on my tasks, not to track my every piece of work. I’m using it to not forget work. I have a couple of phone calls this morning and a phone call this afternoon. I hope to complete one of the workshops today. Maybe.

I have a workout tomorrow and a number of phone calls, so I might not complete anything tomorrow. We will see. On the other hand, I am whittling down my list to something manageable. I no long feel anxious about it. I can see my progress. And, I have managed to blog this week. I am a happy, productive woman.

And, that is what personal kanban is all about.

Are you considering joining me in my Coaching or Project Management workshops in London on May 16 or May 17, 2013? If so, please decide quickly.

I have room for two more people in the coaching workshop. I have room for three more people  in the project management workshop. When those places are gone, they are gone. That’s it, no more. I will run a waiting list.

If you are considering it because you are not sure, email me.

 

Before anyone wants you to make an app for them, make sure they watch this video: slides available here: 

Interview with the bor!sgloger expert panel on the subject of internationally distributed Teams (Part 7)

Part 1: Does distance cancel out efficiency of internationally dispersed Teams?
Part 2: Should internationally distributed Teams be avoided?
Part 3: Scrum Spaces of internationally distributed Teams – the Do’s and Don’ts
Part 4: The Pros and Cons of Electronic and/or Physical Taskboards
Part 5: How internationally distributed Teams can improve their Daily Scrum
Part 6: How internationally distributed Teams can improve their Sprint Planning 1

Stephanie G.: Having discussed Sprint Planning 1, let us continue with your tipps & tricks for Sprint Planning 2. How would you conduct this design meeting?

Ina K.: I would actually say that it‘s quite similar to Sprint Planning 1, apart from the Product Owner not being present. Sometimes the meeting is off to a slow start. If that‘s the case, the ScrumMaster should get involved and start filming people (see Christof’s answer in How internationally distributed Teams can improve their Sprint Planning 1) as well as make sure that the Team members who document the meeting rotate. Once the Team members properly get going, the ScrumMaster can retreat  and remain in a position of observation. Watch the Team – are they interacting enough? Do they seem to have a common understanding? Is everyone adding to the conversation? It‘s important to keep an eye out for such things, as the DevTeam members usually don‘t. Once they actually start looking out for it by themselves, the ScrumMaster has achieved wonders.

Hélène V.: The most important aspect of Sprint Planning 2 is that the common design solution that the Team has agreed upon is visualized and can be seen by all Team members. Only if this has happened, can the distributing of Tasks on a cross-location basis begin. Some Teams think that they do not need any visualisation … all I can say is that distributed Teams who believe this myth have a much higher chance of forgetting important aspects to their design.

Kristina K.: My Team had this issue. The fact that they typed up the Tasks into an electronic tool didn‘t help either, since it sometimes seemed that only the one who did the typing also did the thinking. The fact that the know-how was so unevenly distributed was an impediment in Sprint Planning 2, too. The lack of drawing meant that there was no real common Team understanding of the design – they didn‘t talk about how to implement the User Stories, but rather talked about what singular steps were necessary to implement them.

Bernd K.: We didn‘t really have what you can call a design session either. Sometimes the Team members used the flip charts for drawing, but then I had to take a picture (since the quality of our webcam was not good enough) and send it to the other Team members. This alone would take 5 minutes, by which time the moment for entering in the design discussion was over.

Generally, I did not enjoy Sprint Planning 2 – it often stretched out over three to four hours, which is two hours longer than a Sprint Planning for a two-week sprint should be. The problem was that our electronic tool did not have a word limit for Tasks, meaning that the Team often spent ages on writing them. This did not help to bridge the geographical gap either: the Team members in Romania were rather pragmatic, while the ones in Germany could be called the „philosophers“ – wishing to specify their Tasks and over-thinking the why what, when and where. While the Team dynamic of a co-located Team would have quickly eliminated this discrepancy with smiles or a nervous look, the Romanians were hidden behind a microphone and nobody knew what they were thinking.

Kristina K.: Oh dear, that sounds quite irritating. What I started implementing after a while was to ask the various locations to prepare several design options and to then challenge each other during Sprint Planning 2. In the end, we used the best idea out of all of them and wrote Tasks for it. This ensured that everyone on the Team had actually thought about the Stories, even if they‘re no expert.

Hélène V.: Yes, that‘s what I would recommend, too. After Sprint Planning 1, the Team should do a short mapping of the areas and topics that need discussing. You could then divide up the topics for each location i.e. location A takes the module on the database approach, location B focusses on another solution etc.

Christof B.: I agree with both of you, but I think that the decision of splitting up a Team for or in preparation of Sprint Planning 2 really depends on the Team constellation. If all roles are represented at all locations, I do think that the Sprint Planning 2 can be conducted as group work – meaning that each location grabs its own User Story, does its own mini-Sprint Planning 2 and then presents it to the rest of the Team after 30 minutes. After reviewing the outcome, the entire Team writes the Tasks together. However, this is only possible if both front-end and back-end are present at all locations. This option is not possible if i.e. testers and developers are in different locations.

Stephanie G.: It is so interesting that you all recommend splitting up the meeting, since I actually used to do the same. Only I did not split it in the way of one Story in each location, but rather one person from each location formed a Team, which would together work on one Story (see Pre-SP2 Design Sessions or How to use your Time during a Sprint Change?).

Christof B.: Sprint Planning 2 should not be underestimated. It is certainly not trivial, as it can be chaotic due to the necessary interaction between the Team members. After all, it is not only a meeting, but a creative process, design thinking, architectural brain-storming etc. A lot happens during SP2. I don‘t believe that its doable over the phone. It‘s even nearly impossible to do via video conference. I really think it‘s best if each location works on its own concept during Sprint Planning 2, which is only interrupted by SoS-like coordination meetings where the whole Team gets together again. For example, a design session for 30-45 minutes, followed by 10-15mins of presentation by each location including feedback.

Deborah W.: Funny. I never had any difficulties with Sprint Planning 2, meaning that I could always really enjoy this meeting. I thought it was one of the simpler ones when dealing with distributed Teams. Maybe it was an exception, but my Team members got really involved – even across locations. It was easier than SP1, since there was always less to show. Yes, we did draw a few diagrams and design the architecture, but not for too long. The topic was pretty clear to everyone, so the meeting was concise and short.

Stephanie G.: I love it when opinions diverge as much as yours right now. So before you all get jealous of Deborah‘s Team, let me quickly sum up the main points of advice:

• Just as you would with a co-located Team, make sure to visualize the design concepts, so that all Team members are on the same page. The writing of rough Tasks should only happen at the very end.
• if necessary and possible, split up the User Stories amongst the various locations, where the Team members can draw up the concept and afterwards present it to the rest of the Team.

 

Related posts:

1. Sprint Planning with geographically dispersed teams located in different timezones
2. Pre-SP2 Design Sessions or How to use your Time during a Sprint Change
3. How internationally distributed Teams can improve their Sprint Planning 1

Continuing with the 100 Things You Must Know to Be Effective In Software Development. This blog is going to be as much (or more) personal than technical.  I had already listed The Fundamental Attribution Error on this list.  But I had a great experience (and insight) today that I wanted to share.  First, a quick summary - the fundamental attribution error describes the tendency to blame the...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]

VersionOne has announced the availability of its Spring 2013 release. With the introduction of a new Portfolio Timeline and enhanced Conversations, the new release extends VersionOne’s enterprise agile offering to help customers improve organizational visibility and collaboration and simplify coordination of their agile portfolio management (APM) initiatives. The new Portfolio Timeline allows Project Management Offices (PMOs) and project leaders to quickly get a high-level view of their portfolio of business initiatives, enabling them to see progress and identify at-risk projects. The Portfolio Timeline also allows program and project managers to ...

If you want to save time on a distributed team, this post is for you.

The best way to manage external teams and resources is the Space Manager Tool. Space Manager Tool is available for all Assembla Portfolios. Space Manager provides your team the ability to:

• Share Code with Limited Access
• Share Partial Ticket Lists
• Share a Prioritized Backlog
• Share Tools You Want

How does it work?

Let's start setting up a Master Space and add Child Spaces to them.

The Master Space is the container for the Child Spaces. Child Spaces are filtered spaces of the Master Space.

Say, you have an IT-outsourcing company "MasterSoft inc".

You provide services to a lot of customers. Let's take two of them: "SimpleJava" and "Soft.com".

Of course, you would like to keep customers informed. Also, Child Project members should have access to their company's content.

To achieve these goals you will setup a Master Space. All "MasterSoft" team members (PMs, Developers, Ops, etc) will become members of this space.

To add Master Space features to your Child Space use Space Manager Tool.

It can be installed from Admin->Tools:

Also, "MasterSoft" will need a Ticket Tool to post tasks for all customers.

Each customer company will have own repository in it's Child Space, so the Master Space will not require a repo tool.

At this point you will need Tags for each child project. Tags can be managed in the Ticket Tool Settings, under the "Tags" section.

Tags are also used to mark and filter tickets in the Simple Planner and Cardwall for Non-Child Spaces and Child Spaces without Filter.

In the Filtered Child Space this option is disabled, since it has already been applied.

To create a Child Space you will need to switch to the Space Manager tab:

Finally, setup a new Child Space:

As shown in the form, Tickets will be shared with SimpleJava space, but will be filtered by the Tag "SimpleJava".

This means that only tickets with this Tag will be displayed for the Child Space. Also, all the tickets, created from "SimpleJava" Child Space will be tagged with a "SimpleJava" tag. Nice, isn't it?

Now the only thing required, is to invite SimpleJava Team Members in the Child Space, and set up their role (member, watcher or owner).

Note, that all the roles from the Master Space will be delegated to the Child Space. So, all the Master Space members will be able to access all the Child Spaces with the same role, they have in Master Space.

The Child Space can be accessed directly from the Space Manager page or from the top bar dropdown navigation once you are in the Master Space.

The Workflow

It's time to talk about how the whole stuff works and what is the basic workflow, for the MasterSoft use case.

Bob is a QA specialist from "MasterSoft", who found a typo in the application, just deployed to the Google Play Market.

So Bob opens a new ticket from the Master Space, and tag it with "SimpleJava" tag.

Quite simple.

Now all the developers who work with "SimpleJava" will be able to see the new ticket in the filtered Child Space, as well as SimpleJava team will be able to track the progress.

So what are the results?

• Tech Leads and Developers are more focused on their work in Child Spaces
• PM's can still see the list of tickets for all Feature Teams, filtered by some condition (say fix-today tasks) in Master Space, alongside with filtered Backlog in the child space.
• Your customers can track the Prioritized Filtered Backlog in the child space
• A customer is prevented from accessing other customer's content
• You can add any usual tool (Wiki, Messages, Repositories, e.t.c.) to the Child Space
• You can tag a ticket for more than one team, say "SimpleJava" and "Soft.com". This introduces even more flexibility into your process.

To find out more about Scaling Teams and Resources, you may want to read Beyond the Scrum Roadmap article.

If you haven't  try Space Manager for your projects yet, you definitely should https://www.assembla.com/subscribe-portfolio.

I’ve been busy crossing work off my list. And, as with all of us busy people, I’m adding more work to my list. I feel as if I’ve accomplished a lot this week.

It’s just about time to rewrite my list, because with the cross-outs, it’s hard to see where I am. It’s time to go to draft 2 for the workshops, which might be the final drafts for the prose. I will be revising the simulations and interactions during the week. I hope to complete them by the end of the week. I do want to complete the workshops by the end of the week. I will feel more comfortable.

I had some items pop up on my urgent queue: I did go vote.

In yesterday’s post, there is a comment from Lukas, about how he likes rewriting his list, because he gets to reassess the relative rank of each item on the list when he rewrites the list.

If you use stickies, in a real personal kanban, such as I suggest in Manage Your Job Search, you pick up the stickies and put them down. Because you handle the stickies, you have a way of checking in with yourself to reassess the relative value of each item on your queue.

Okay, off to work again today. I’ll check in with you again tomorrow.

Klaus Bucka-Lassen discusses the estimation with story points in Scrum. Story points are a different way to estimate features in Scrum. Story points are a measurement of a feature’s size relative to other features and not a measure of the time needed to complete a feature. Video Producer: http://gotocon.com/Further reading on Agile estimation * Story Points: Why are they better than hours? * Why I Don’t Use Story Points for Sprint Planning * Transitioning From Time-Based to Relative Estimation * Stop Using Story Points * Relative Estimation Communication

Here’s another extract from my book-in-progress “The Programmers Guide To People”, the first few chapters should be available at the end of May on LeanPub. You can sign up to be notified when it is here

The Oxford Dictionary defines an assumption as: “a thing that is accepted as true or as certain to happen, without proof”. We constantly make assumptions. Sometimes we are aware of them, often we’re not.

When we attribute blame we make an assumption about the other persons behaviour, often without really knowing the reasoning behind the action they took. We make this type of assumption as a defensive behaviour rather than through any rational thought. As we have already discussed these types of assumptions damage relationships and our ability to learn from problems. Testing these assumptions is easy, we can talk to the people we are blaming, listen, and ask them about another assumptions we make when hearing their explanation. The deeper we go into our questioning the more we can scrape away the assumptions and get to the root of the problem.

When something happens we make assumptions about its cause. We can’t resist attributing simple causes to mistakes and successes when the reality is far more complex. Even when there is little evidence we prefer to make an assumption then be left with no cause. Even if our cause may be valid there may be many other factors involved that we fail to consider. We have a strong bias towards finding simple causes to complex problems and certainty because these means we don’t have to think so hard. Unfortunately simple causes can be misleading.

We make assumptions about the best way to do something. We follow others when we see them having success with a tool or method even though our context may be very different. When someone we look up to declares something to be wonderful we stick a halo on that thing and follow religiously without really testing if it will work for us. When we discover that something does work for us we like to assume that it will work equally well for others too.

We use assumptions to simplify things when the reality is too complex for us to understand. We create models with these assumptions that allow us to predict system behaviours and these work well until we forget they are only models. Our simplified models of reality must be tested continually and improved. Reality continually changes, yet we tend to stick to the same old assumptions.

We make assumptions about other people’s needs. Rather than ask or try to understand the people we are building the software for, we make guesses about their needs. This helps us develop software faster, but are we building the right thing? This question becomes even harder when we realise that our customer is also making assumptions about what they need. To discover what is really needed we must test our assumptions by allowing customers to use the software while we are building it.

We make assumptions about what other people mean when they say something. Our language is limited as is our ability to use it effectively, this results in us guessing at what the other person means. We are reluctant to clarify exactly what was meant for fear of embarrassment if we have got it wrong. In a conversation both people are making assumptions. In a meeting a large number of people are making assumptions many of which will be wrong. Much of the conflict we see in work comes from misunderstanding rather than genuine differences of opinion.

We need assumptions, but we forget that’s what they are. The problems above aren’t because we make assumptions they are caused by our unwillingness to test them. The more pressure put on us, the more assumptions we will make and the less likely we are to test them, resulting in a higher chance that the assumption is wrong. Well that’s my assumption.

What do you think? Is this inline with the way you think about assumptions? What other assumptions do we make? Should we take more time to test our assumptions?

The developers of Project Open, an open source enterprise project management package, have announced they are releasing version 4.0 of the software application after extensive testing of the release candidate. Among the new interoperability features of the package is the ability for projects to be imported into Project Open from Microsoft Project, edited in Project Open and then exported back to Microsoft Project. The software now has a configuration wizard to simplify integrating Active Directory and SharePoint, which will allow projects to store their documents on a SharePoint server. The Linux ...

In Scrum: The Unity of Knowing and Doing, I discussed the two basic abilities of human beings: knowing and doing. In terms of Scrum, inspection is about knowing, adaption is about doing, and transparency unites knowing and doing. From a team persp...

One of my team's daily standups (or maybe a standaround; not sure). That's me in the middle. Since then we've added a few more ladies to the team!

StandUp is a cornerstone of any agile practice.  It runs like a well-oiled machine at most agile shops. You get the talking stick (or ball, or the coolest piece of swag from your last agile conference (for the record, it was the V1 ‘Do Me Daily’ t-shirt), and you quickly and very professionally (even though you’re wearing cutoffs and flip flops) speed-speak your status so you can get back to your console and start slinging code asap:

“Yesterday I made the changes to the Uber-Widget that Bob asked for, and today I’ll be working with Matthew to get that styled up and looking good.  I may run into an impediment if Matthew isn’t available. When that’s complete, I’ll be ready to plan the next story.”

Then you pass the talking stick to the next team member like you’re shooting a 3-pointer (cuz you’re cool like that and it’s NBA playoffs time).  And so it goes around the circle until the ScrumMaster gets the stick in his hot little hands and tells everyone Matthew is out sick so let’s hold off on the Uber-Widget styling and jump right into the next story.

That’s how it’s supposed to work, right?  Tell the team what you’ve done, what you’re currently working on, and any impediments you’re facing.  The ScrumMaster then leads a discussion to resolve any impediments so that the team can maintain forward progress.

And it does work!  That’s the beauty of it – excellence only comes with practice, and we get to practice standup every day.  E-V-E-R-Y damn day.  So we’re pretty damn good at it.

However, even the most rigid training schedule needs a shake-up now and then.  Here at VersionOne, we have the occasional StandAround instead of a StandUp.  StandAround usually happens on a gray, rainy day when half the team is out sick.  You know it’s going to be a StandAround when the scheduled StandUp music gets through an entire song before the team manages to mosey over to the meeting area.  Once everyone is together, blowing on their fresh coffee, idle chatter bubbles up here and there.  Instead of the git-r-done vibe of StandUp, StandAround has a laid-back, get-to-know-’ya cachet.  Team members catch up, crack a few jokes, and then get on with their day.

Keeping the team healthy is just as important as forward progress.  So every now and then, have a StandAround.  Let it happen.  It’s OK!

 

Continuing with the  100 Things You Must Know to Be Effective In Software Development. I appreciate the comments I've been receiving on this project. While I am not changing the title as yet, I believe it would be more appropriately named: "The 60 things you need to know, the 10 things you need to forget and 10 other useful things to be effective in software development."  A bit long, I...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]

I’ve made great progress on Day 1, and I wasn’t even in the office all day!

You can see I’ve added more todos, at the bottom of my queue. I discovered two urgent todo’s. I had a call-back, to reschedule a doctor’s appt this week to next week, and to vote today. (We have a primary election today for a special senate election in June.)

And, since I’m cheating on how to do a real personal kanban, I thought I would at least describe for you how to do real personal kanban over at Personal Kanban for Your Job Hunt.

You can see now there is a huge drawback to my list. I will have to rewrite my list, instead of just moving the stickies off. This is why in personal kanban, the right way is to not have a list. If you move the stickies, you don’t get this list nonsense, with lines crossed through.

Well, most people don’t have vertigo, either. So, tough. Okay, enough being meta today. On to the real work of the day.

If you missed part 1, here is the link: Personal Kanban and Iterations, Day 1.

We are excited to announce a new major spring 2013 release!

TargetProcess 2.24.0 includes quite a few small and big improvements. Check what we’ve done to help you work better, faster, more comfortably.

10x faster search

We’re close to less than 1 sec search time, but this new search is not only fast. The search results look nicer now, and you can open them both in new tabs and as a pop-up.

Read more  about the new fast search in our Help portal.

Relations and Relations Network Diagram

Quite often one piece of work is “informally” tied to another piece of work. For example, the core team is working on an API, and the other teams are dependent on the core team’s progress. Keeping such informal dependencies in your head can be tiresome…

Starting from 2.24 you can track such informal dependencies right in TargetProcess as Relations!

Relations Network Diagram represents a network of related entities:

Relations can be created for any entity (i.e., user story, task, bug, etc.), and they can be of great help when planning or prioritizing. Be sure to check the article about Relations in TargetProcess Help Portal. It has more screens, and explains how Relations are helpful in planning and progress tracking.

New Visual Reports:Process Control Chart and Lead and Cycle Time Distribution Report

The Process Control Chart shows cycle time distribution for completed entities (user stories, features, bugs, tasks, requests) within a certain time frame. Check the screen below. If you see user stories between the warning limit and the control limit lines, this is suspicious. If a user story goes beyond the control limit line, this is really a bad thing, and you should investigate why it took so many days to complete. These limits are calculated statistically; they depend on the overall distribution of stories in the chart.

You can find a comprehensive description of the Process Control Chart here. It includes more screenshots and some examples on how the chart can be used.

Note the new powerful filters. You’ll see more of them later. They can now be used to filter out the entities in the Relations Network Diagram and in the new visual reports.

While the Process Control Chart quickly spots the entities that took too long to get done, the Lead and Cycle Time Distribution report helps you make realistic forecasts. You can filter out any entities, just as in the Process Control Chart:

Read more about Lead and Cycle Time Distribution Chart.

Improved Views

There’s a bunch of nice improvements to the views: quick convert (all the properties are kept intact for the converted entities), assign 2+ people, switch project quickly in the Info box for an assignment, auto-convert URLs to clickable links.

Besides, starting from TargetProcess 2.24 you can add up to 60 custom fields to any entity.

New History REST API

Check out the  new History API in TargetProcess REST API.
The new API will track state changes for Bugs, Feature, Impediments, Requests, Tasks and User Stories.
More info on the new History API in TargetProcess Help Portal

Im Psychologiestudium war die Wahrnehmungspsychologie eines meiner Lieblingsfächer. Ich kann mich noch gut daran erinnern, wie mein Professor zwei Fotos zweier Männer mittleren Alters nebeneinander hinlegte: Der eine im teuren Armani-Anzug, frisch rasiert, wie aus dem Ei gepellt. Der andere im Freizeitlook, Drei-Tage-Bart. Der Professor fragte uns: “Bei welchem der beiden Herren würden Sie eher eine Lebensversicherung  kaufen?” Interessanterweise entschieden sich fast alle Studenten für den Anzugträger und wurden damit Opfer des Halo-Effekts (vom Griechischen hàlos = Lichthof). Der Halo-Effekt (oder Hofeffekt) ist einer der am häufigsten auftretenden Beurteilungs- bzw. Wahrnehmungsfehler. Er besagt, dass die Dominanz einzelner Eigenschaften bzw. Attribute den Gesamteindruck einer Person bestimmt und auf diese Weise die Wahrnehmung weiterer Eigenschaften überstrahlt. So können Äußerlichkeiten wie das Aussehen, die Kleidung oder gar die Körpergröße den Ausschlag dafür geben, ob man z.B. kompetent oder freundlich wahrgenommen wird. Das Märchen “Des Kaisers neue Kleider” von Hans Christian Andersen ist ein schönes Beispiel für die kritische Auseinandersetzung mit den Auswirkungen des Halo-Effekts.

Ein ScrumMaster sollte daher stets auf der Hut sein. Er sollte zumindest um den Halo-Effekt wissen und nicht nur sich, sondern auch sein Team vor seinen Fallen schützen. Denn es ist gerade das System “Team”, das den Sirenen des Halo-Effekts auf besondere Weise verfällt: “teams tend not to be blamed for their failures“. Charles E. Naquin and Renee O. Tynan von der Universität von Notre Dame fanden in “The Team Halo Effect: Why Teams Are Not Blamed for Their Failures”  Nachweise dafür, dass “the nature of the causal attribution processes used to diagnose failure scenarios leads to individuals being more likely to be identified as the cause of team failure than the team as a collective. Team schema development, as indexed by team experience, influences this effect, with individuals who have more team experience being less likely to show the team halo effect.”

Wenn das Team halo-ziniert

In zwei interessanten Studien belegen Naquin und Tynan ihre Hypothesen, die für jeden ScrumMaster Anlass sein sollten, sich und die Performance seines Teams kritisch zu hinterfragen. Ich gebe diese Empfehlung, weil Teams, genauso wie Individuen (vgl. Attributionstheorie von Weiner, die zu den kognitiven Emotionstheorien zählt), zwar die Ursachen ihrer Erfolge den eigenen Fähigkeiten zubilligen, Misserfolge werden jedoch meist (nicht immer, aber überwiegend) äußeren Einflüssen (und eben nicht mangelhafter Planung, unzureichender Kommunikation, schlechter interner Aufgabenverteilung oder fehlender Schwerpunktbildung) zugeschrieben. Der selbstkritische Blick wird durch die eigene Hybris verfälscht und durchgehend abgeschwächt. Selbst Retrospektiven, also die eigens für ein Team geschaffene Plattform, offen, direkt und schonungslos eine Inventur der eigenen Performance zu machen, um möglichst produktiver zu werden, geben im Schritt 4 “Was könnte verbessert werden” ausreichend Gelegenheit für Halo-zinationen: z.B. “Wir haben viel zu viele Meetings, um überhaupt was arbeiten zu können”, “Wir sind viel zu heterogen, um unsere Arbeit zu teilen oder an den gleichen Aufgaben gemeinsam zu performen”, “Wir können das SP1 und das SP2 ruhig mischen. Das geht doch dann alles viel schneller”, usw.

Das Phänomen des Halo-Effekts ist typisch, menschlich und nicht vollkommen auszuschalten. Aber es lässt sich eindämmen, indem der ScrumMaster es offen anspricht und den Mut hat, seinem Team den Spiegel vorzuhalten. Er ist der Prozesshüter. Er ist verantwortlich, dass die Produktivität steigt. Gelingen kann das, wenn das Team seine Leistung ohne Halo-zinationen beleuchtet und auf dieser Grundlage hinterfragt. Nur so kann die “Weisheit der Vielen” zur Entfaltung kommen und die wirklichen Stärken einer Gruppe zum Ausdruck bringen. Das Ganze ist immer mehr als die Summe seiner Teile und demnach sollte der Fokus des ScrumMasters immer auf beiden “Systemen” liegen bzw. sie gleich wichtig analysieren und verbessern wollen: das Individuum und das Team. Ich sehe viel zu selten, dass ein ScrumMaster das Team als Ganzes betrachtet und coacht (außerhalb der Retrospektive). Die Kunst dabei ist, das Team so zu sehen, als wäre es ein Individuum. Aber eben eines mit unterschiedlichen Charakteren – eine ganz besondere Herausforderung.

Literatur

Charles E. Naquin &Renee O. Tynan (2003). Team Halo Effect: Why Teams Are Not Blamed for Their Failures. Journal of Applied Psychology Copyright 2003 by the American Psychological Association, Inc.
2003, Vol. 88, No. 2, 332–340. University of Notre Dame

ScrumMaster sind Meister der Effekte und Illusionen (Teil 1) – der Othello Effekt

Related posts:

1. Education Paradigms & Softskills
2. People needs to “hear and view” colleagues.
3. People needs to "hear and view" colleagues.

Thinking on Jay's suggestion at his presentation (DFW Scrum, AgileFest!) to create an Agile Playbook; I'm wondering why scrum masters don't do this more often.  Well, guess what?  It's very good advice.  The authors Chip and Dan Heath give this very advice in their new book Decisive: How to Make Better Choices in Life and Work.

Why do teams continually over estimate the number of stories they can complete (potentially shippable tested working software) in a sprint?  There are many reasons.  But what play would you run next sprint if you were the team?

If your team already has an agile mindset, then the natural play will be to reduce the amount of work they are bringing into the sprint.  The result of this play is to return the team to a consistant delivery of value.  Resulting in a predictable velocity.  This predictable velocity will be used for projecting the release scope or date.

The problem for many teams is they do not posses an agile mindset.  Therefore this play appears counterintuitive to them.  So of all the plays they could run, which will move them toward an agile understanding and give them feedback?

Which play do you run in this situation?