Cred-scraping

This occurs where people connect to you as an industry expert in order to convince others that they are interested, conversant or even experts in their own right in that field. This also applies to endorsements. 

Example: software recruiters connecting to practitioners in the software field; similarly with endorsing a recruiter of business analysts as a business analyst themselves. Which a is not true, their expertise is in recruiting or relationship sales. 

Effects: false positive results to specialised searches; noise in the system; wasted time. People looking for recruiters – in this example – can’t actually find them. 

PO 101 and insightful given the time of year

Interesting set of guidance from Roman Pichler…

>> http://www.romanpichler.com/blog/the-product-owners-checklist-for-the-first-sprint-in-scrum/

Business Analysts cannot be the “proxy” Product Owner

As an avid Agilist, a consultant and a BA for many years – I would like to assert that the trend of positioning the business analyst (BA) as a proxy for the Scrum Product Owner is not viable.

Practically, there are limitations to the idea. I feel that two key facts make the idea absurd:

1. the BA profession is struggling to create its own identity, therefore defining it externally as Agilists is even more confusing for BA practitioners and the entire profession. This view is built on the work I have conducted with the International Institute of Business Analysis (IIBA) in analysing the results of the annual IIBA survey which showed that many BA leaders are still searching for a purpose of their departments and teams; see two analyses here and here.
2. as a consultant, analyst and delivery manager, the pursuit of the coveted sign-off was ever-elusive – it was a commitment by the business users / sponsors / stakeholders to the definition of done. And to believe that a self-respecting stakeholder will empower a BA (traditionally part of IT), or anyone else, to act as a proxy for that commitment is not only laughable, it is deluded.

I don’t mean to sound harsh and maybe this is an opportunity for the BA profession to jump on the Agile bandwagon and be defined by the environment in which it finds itself – but this approach is not pragmatic in context of the above.

Perhaps in an evolution of the art of systems development, it won’t be a ridiculous idea. But that is just me being aspirational.

 

Agile fallacies – the sprint goal

In the last few weeks, I have been reflecting on Scrum training material, some team behaviours and other articles. My mind sticks on the point of sprint goals and there is some disconnect between the various experiences that I have had.

IMHO…

The sprint goal is not the stories, tasks, defects, PBIs (whatever you choose) that are in the scope of the sprint. And we don’t commit to the stories either. We commit to the sprint goal. The sprint goal should be an expression of the value delivered in the sprint in simple terms – like advanced searching for property, link to Twitter and G+, etc. There is some rhyme behind the reason too…

If we commit to the stories, then

• we miss the point of delivering what is really required
• we focus on abstractions of value rather than value itself
• we can’t create the concept of stretch
• we *may* overextend ourselves

And for the love of your chosen deity, can we avoid the use of “the ability to…” type statements in the definition of the goal. Simple is simple, so let the language reflect it.

Boring retrospectives – part 13 : Helping Hands

Perfect “game” to play at the start of a project or whilst building up a team. Also a good reminder “game” after a sustained period as a team… great post 🙂

SkyCoach

Working together is one of the most important success factors in an agile team.   Individual work will not be enough to deliver all the user stories before the sprint is finished.  Daily standups help to foster this communication, but it has to be a focus throughout the entire working day.

That’s why it is useful to focus on this principle once in a while during a retrospective.

Helping Hands is a useful exercise that gets people thinking about the objectives of their own role and how they can help others to reach theirs.

As a facilitator, you start by drawing a pivot table that contains all the different team roles. You explain that the team first needs to fill in the objectives of each role. Roles that are filled in by 1 person (such as PO and SM) can write their objectives down on the pivot table, others will have…

View original post 129 more words

Team safety

I recently had a release retrospective where there was a comment about our anonymous suggestion box (see tweet above)… this got me thinking: how do we ensure team safety? and not in the HSSE sense. In the mental, team-focussed, interpersonal sense. Here’s a shot at four things I feel make a difference; add your thoughts in the comments below.

• Listening – being an active listener is so important; asking a relevant question and actually responding in body language and consciously reflecting the statements and/or answers given.
• Noticing – once you’ve heard something, take a small action, remember to take one in the future. Surprise your team, they want to be noticed and remembered, we all do.
• Being vulnerable – everyone responds, so someone needs to take the first step right. Teams will take the lead from a leader being vulnerable. It doesn’t have to be a massive thing, just be human – we all have feelings show yours.
• Role modelling – the above need to be lived out… and genuinely! Intent for intent’s sake is flaky and totally visibly to your team. “Be the change you want to see in the world” as Gandhi said.

…and you can’t fake any of these; just by the way. That’s the Zen of intent.

How to prepare for a daily standup

SM and PO guidance for the stand-up 🙂

SkyCoach

The daily standup has become a routine in the lives of many people in software development.

78% of all agile teams hold daily standups, according to the 2011 State of Agile Development Survey from VersionOne.

Each day, at a specific time, teams gather around the task board and plan their next actions.  Although this practice has been around for many years, it still feels awkward to some extent.  Especially for the Scrum Master and Product Owner.

Should we also explain what we have done and are planning to do next? Won’t this bore the team? Do I just stand there, and listen?

I’ve been in both roles before and will explain how I took part in the daily standup.

As a Scrum Master…

… I always prepare myself for 5 minutes before the daily standup.

• What have I done that is useful information for the team?
• What am I…

View original post 318 more words

Landmark articles: flaccid scrum

Landmark articles: flaccid scrum

Context: people

The nature of the work that people currently do, the goals of their appraisals and the attitude of those who appraise them will heavily influence their desire to adopt new practices and behaviours.

Adoption mashup

How do we blend Seth Godin’s ideavirus, Gladwell’s Tipping Point agents (http://en.wikipedia.org/wiki/The_Tipping_Point_(book)), diffusion of innovation and the Hype Cycle into something that can make some sense to ourselves and others about understanding adoption, its relevance and resistance?

Ideas on a postcard.