Advertisements

General Musing

blaze your trail

Posts Tagged ‘agile

Why Re-estimate User Stories? #scrum #agile #xp

with 4 comments

On the SCRUM Development list two questions often pop up, I call them the why and when of re-estimating. There are few defined rules on re-estimating, yet estimating and re-estimating is an important part of backlog grooming. Which is why this is a recurring question in many SCRUM fora.

Why should we re-estimate user stories?

Read the rest of this entry »

Advertisements

Written by Daniël W. Crompton (webhat)

August 19, 2011 at 8:25 am

Posted in business, programming, risk

Tagged with , ,

Continuing Our Solitary Existence #xp #agile #scrum #programming

leave a comment »

It’s thought that programmers have a solitary existence, in hacker movies they are often depicted as being behind a screen in the dark working on their own. Even the popular media images of programmers that are loners. As any programmer knows this is far for the truth, collaboration mostly benefits development. Sharing tasks and bouncing ideas of other developers makes the end products better. Yet with the exception of discussions the actual development task is performed by one person behind one computer.

There are many studies which show that there are even better ways to work, collaboratively create and discuss. Taking all the benefits of working as a team and sharing knowledge reduced to one continuous process rather than incremental tasks. It’s called pair programming, and studies have shown pairs can deliver 127% of what they deliver working on their own.

Read the rest of this entry »

Written by Daniël W. Crompton (webhat)

July 21, 2011 at 5:40 pm

Posted in business, programming, risk, work

Tagged with , , ,

Meetings and more meetings #scrum #agile #xp

with 6 comments

In a recent Popular Science article Science Confirms the Obvious a number of studies are examined on some seemingly obvious subject. I’ll leave the discussion on the value of the studies to the article and focus on the result of a study on Group Dynamics: Too Many Meetings Make You Grumpy.

Meetings are usually seen as an interruption in to the work which needs to be done. Meetings can often be complementary to the work which needs to be done, whether it is in defining the tasks, the path or the result. Meetings can be a good way of getting the team aligned, and days chock-full of meetings cuts into time which can be more effectively directed at tasks. They are sometimes seen as a team building exercise, and although brainstorming no holds barred meetings are part of a creative process they are also few and far between.

While brainstorming on this I realized that this is also an example of role-based actions, as I discussed in my review of the Lucifer Effect. The system here is not a prison, as in the Stanford Prison Experiment, but the office environment. The roles are directors, manager and staff. Is holding meetings what is expected from these roles?

What’s the solution?

“Organizations [should] be sensitive to the number of meetings employees are required to attend,” is a suggestion from the researchers and “formal guidelines” for meetings. Which means setting a agenda before the start of the meeting and sticking to it. Time boxing is another effective way of reducing the time spend, time box the agenda items and the whole meeting. When there is a need for a longer meeting – > 1 hour – allow for coffee and/or smoking breaks.

Written by Daniël W. Crompton (webhat)

June 16, 2011 at 3:00 pm

Posted in business, lifehacks

Tagged with , , ,

Information Overload #scrum #xp #agile #risk

with 2 comments

After reading the Newsweek article “I Can’t Think!” I started wondering what the consequences are in SCRUM and XP teams of information overload. In my experience of SCRUM and XP there is a lot of information exchange, including Pair Programming and Test Driven Development even more possible information sources are forming a threat to the developers.

One of the best examples of my own experience is when I was working with ESB platform and Java Messaging (JMS). I had had no experience with the former and a reasonable amount of experience with the latter. I was asked to explain the inner workings of the software package I had had little experience with. The answer: “It does some magic, with a secret sauce!” was not enough to counter the fears of the PO who had made the choice to use the software. This caused me to need to get far more information about a subject to be able to explain in layman’s terms what was occurring.

The additional information I needed to collect was a stone around my neck for the initial introduction and understanding of the platform. And with the benefit of hindsight I should have said that I needed to get a basic understanding of the platform before committing to the demands of the PO. The downside was that we needed to be able to estimate the User Stories, and an estimation of 100 was a little excessive.

Read more articles on , or

This is an example of information overload caused by not able to put the learned information into a context. And there are a number of cases which of Information Overload which can occur in Agile methodologies that may cause teams to temporarily derail, as the article notes:

The brain is wired to notice change over stasis. An arriving email that pops to the top of your BlackBerry qualifies as a change; so does a new Facebook post. We are conditioned to give greater weight in our decision-making machinery to what is latest, not what is more important or more interesting.

Which in practice means:

  • incoming mail, text or instant messages
  • meetings
  • too many search results
  • other interruptions

As the article further notes:

Experts advise dealing with emails and texts in batches, rather than in real time; that should let your unconscious decision-making system kick in. Avoid the trap of thinking that a decision requiring you to assess a lot of complex information is best made methodically and consciously; you will do better, and regret less, if you let your unconscious turn it over by removing yourself from the info influx.

These are issues where the SCRUM Master is the gatekeeper to the team, and should factor in time in the day when these interruptions can take place.

Image source: Jerry Wong

Written by Daniël W. Crompton (webhat)

March 14, 2011 at 8:31 am

Posted in programming, risk

Tagged with , , , ,

Thinking of problems that don’t exist, and fixing them #agile #scrum #xp

leave a comment »

Currently I’m developing something which has a learning curve, not so much because it is difficult to understand it, more because there are portions of it which seem illogical. I could delve into the issues I have, and this may become a more technical article, and that’s not what I want to discuss here.

The current project I’m working on has a reasonably complex business logic which it implements, adding to that a untried and unknown technology and it’s a receipt for a difficult sprint – meaning it’s difficult to correctly estimate the complexity of tasks within the User Stories. This makes it ideal for applying Test Driven Development. The advantage of TDD in this case is that an assumption is made when writing code, expressing this assumption in a test before writing the code makes it easier to verify this assumption.

Programmers, including me, are very good at “thinking of problems that don’t exist, and fixing them.” Test Driven Development gives me the advantage that I can express my expectations in a test, and assert the requirements which need to be met for a test to pass or fail. In this way I can postpone the fixing of this fictitious problem until the time that an issue occurs.

Read more articles on , or

An added advantage is when issues occur. Programmers – like me – are often focused on the details of the implementation, which means that we will see potential issues and blame side-effects of the current code rather than focussing on the issue which is occurring. Creating incremental tests as evidence that the code is working correctly can help bolster your position and support your argument that the error is outside your code, it also has the advantage that other developers will immediately see that their changes are causing side effects. This is far more effective than creating a one-time proof.

Image source: Jerry Wong

Written by Daniël W. Crompton (webhat)

March 8, 2011 at 9:35 am

Posted in programming, risk

Tagged with , , ,

Bad Sprint: What next? #scrum #agile #xp

with one comment

I’m sure you’ve had the feeling on the last day of the Sprint that the way it went was awful:

  • build environments broken for
  • User Stories were badly estimates
  • team members who had troubles
  • team members were stressed about completing their User Stories
  • new team member
  • Project Owner wasn’t available
  • not enough story points completed
  • User Stories left uncompleted
  • etc.

Let me put you out of your misery, it was worse than you think. 😉 As the Scrum Master you probably feel bad, just think how your team feels. Like you they are now possibly demotivated and doubting themselves, and however much it was their and your fault it is now your task as Scrum Master to help get your team back on track.

Who’s going to motivate me?
Anonymous Scrum Master

To answer that question you must realize that only you can motivate you, and that goes for your team too. Your task is not to motivate them, but to facilitate them to motivate and trust themselves and each other. There are many methods which can be used to achieve this, and I invite to to explore these to motivate yourself so you can motivate your team to become the best Scrum team.

Read more articles on , or

Now it’s up to you and the team to align the team to the next Sprint, and complete the next Sprint with a win.

Basics About Employee Motivation (Including Steps You Can Take)

Image source: Jerry Wong

Written by Daniël W. Crompton (webhat)

January 26, 2011 at 7:09 am

Posted in programming, risk, technology

Tagged with , , , ,

Scrum: Story Points for Bugs #agile #xp

leave a comment »

As I mentioned before I mostly work in an Agile Scrum environment, with a little eXtreme Programming thrown in. This week I saw some messages go on the Scrum Development list by asking about assigning Story Points to bugs. There were some good opinions going by, and I hold to the idea that bugs fall into two categories:

  1. Programmer Errors
  2. Missed Requirements

The first is unavoidable, although they can be reduced with automated testing based on the User Story and Unit Testing of the underlying code.

As a users I want to move relations to a company

The second is an issue for the Project Owner, when the PO describes the User Story and leaves out certain requirements I believe that those are out of scope for the User Story. I’ll give an example of a User Story right.

The PO might neglect to add that the user might want to create a new company or a new relation in this flow and actually meant to word the User Story below. And naturally a User Story as in the example is still acceptable when the PO adds the requirements to the User Story description.

As a users I want to add or move a new or existing relations to a new or existing company

It’s also a task of the Scrum Team Members to ask the questions which will uncover these deficiencies in the User Story, so that deficiencies in the requirements are avoided.

Read more articles on , or

Image source: Jerry Wong

Written by Daniël W. Crompton (webhat)

January 21, 2011 at 8:13 pm

Posted in programming, technology

Tagged with , , ,

%d bloggers like this: