OpenAgile and related stuffs!

Posted in agile bangladesh group

Guys!
can anyone enlighten me here? i’ve read an article yesterday on OpenAgile,
which actually drew my attention, you can read it here

it seems to me a combination of lean and scrum, they kept nearly synonymous terms adhered from scrum world.
so far i can understand, they want to keep it open and collaborative. where scrum is religiously maintaining all related practices & terms otherwise inferior complexion is created through ScrumBut.
here is a peek from the blog -

….Another major difference between OpenAgile and Scrum is how the community operates. OpenAgile is an open-source method that has a specific structure for community involvement that allows for continuous improvement of the system. Scrum is closed. It is closely managed by it’s founders and this has led to challenges with the method becoming dogmatic. OpenAgile is meant to constantly evolve and grow…..

so it seems like OpenAgile will be an openly accepted ScrumBut. Sounds to me cool! again,
i wish they will keep it as thin and more adaptive like lean (3 processes)  & scrum (8/9 processes)

from my understanding, prescriptive process is always rigid and provides less option to adapt companies own branded culture thus it might fail or irritate everyone. or it might ended up with cloning the same formal attitude.
probable this is the reason why most of the creative companies create their own way to ensure everyone get’s chance to be creative.

on the other side, less prescribed process such as lean can motivate you to learn how to do better in what situation. gradually it helps you to come up with your own process.
but one problem might happen, people used to pretend they understood the principles very well, in reality, they actually didn’t get it. thus they miss use it. hence it becomes burden and becomes unstable.

it seems me, like writing all logic in View rather not understanding why MVC (model view controller) and why those separations are needed. MVC got very few principles (only 3 infact) but you got bunch of other practices adhered from community, design patterns and technical prophets (mentors _)

best wishes,

Maintenance sprint and visualizing progress over Whiteboard

It’s quite a long time, i haven’t shared anything over my blog. after thinking a while, i decided to share about our maintenance sprint.

since we have been (tekSymmetry) moving from traditional project management to agile project management. as usual we are struggling and learning through our faults and adjusting, adapting and correcting accordingly to accommodate agile in our family.

agile project management seems very simple in theory and easy to transform but in reality it has so many mental and understanding related conflicts which we are stucking and discovering. yes we should have followed this and that.

for those who just started and don’t like to get in argument. you just start with scrum first, & follow all prescribed processes (learn through adapting approach.)

after working on our project for last 7 months and completing more than 20 full and short (in our case, full = 2 weeks, short = 1 week) length sprints. we reached to a point where we are feeling much confident with our process adaptation. here i will demonstrate how we are managing our maintenance sprint.  definitely our way of managing sprint won’t be the best solution for every contexts.

what is maintenance sprint?

before i proceed, i should explain what is meant by maintenance sprint.

illustration of our sprints schedule

here in the picture, you could notice few greenish circles, which we call maintenance sprint. maintenance sprints are planned for supporting a release with related bug fixing. as you know most of the software releases don’t come up with 100% bug free, it comes up with lot of known and unknown issues. to protect our visitors we keep maintenance sprints to provide continuous updates and hot fixes (;)).

how are we doing the maintenance sprint ?

Usually we are doing the following tasks during a maintenance sprint -

• Product owner prioritize the issues and provides us the list
• Sprint planning meeting with client
  
• Team select implementable issues
  
• Product owner can reshuffle and prioritize issues before sprint kick starts
• After everyone agrees (team and product owner) team tags all issues (in issue tracker) with the target release version (ie. 0.12.2)
  
• Daily team stand up meeting
  
• Team provides feedback on client’s reported issues during the day time.
• Daily reporting (we call it end of the day report)

So, how are we utilizing the white board ?

well, first let me show you our white board -

illustrating maintenance sprint white board

Global TODOs:

During the sprint day, this portion of the board is synchronized and maintained. we usually enlist the following topics -

• Major issue
• Task which requires feedback
• Impediment
• Any events which requires our (team) attention
• Any collaboration requirement (ie. need feedback ASAP on issue #2034)
• Any issue which we need to remember. (ie. Send report, deploy before leave the office)
• When tester finds problem during testing, they write it down on the board with red pen
• Every day during stand up meeting we write down all events/tasks/todos on the board.
  

Status BOARD:

This portion of the board is similar to scrum task board, instead of putting sticky paper we use marker to write down the issue number.

when we make progress we move issue from WIP (work in progress) to WFF (waiting for feedback) or WFT (Waiting for test). later our tester moves them to DONE. actually, rather moving physical sticky paper we wipe out the previously written text and write it again on the new column.

this board is maintained through the whole day. whenever we take new task we add it on WIP and when our task is completed, we move it on Waiting for test queue.

we follow the following rules -

• per person only one WIP (work in progress) item can be selected. (taken from kanban)
• whenever we make progress it will be reflecting the board (developer wipe out from WIP and move to next status)
• tester keeps his eyes on “test” column of the board, they eagerly wait for the change on this column
• if tester finds some problem with the issue, the write it down on “global todos” portion of the board in red pen.
• developer can retake any issue (if tester reported not resolved over “global todos”)
• during stand up meeting development team can discuss which issues need to be resolved first.

Daily report:

At the end of the sprint day, we generate a report from the board and send them to every stakeholders, clients  & management. we keep this report very simple we add the 3 parts in the daily reporting -

• what we have resolved
• what we working on
• what we have tested

all of these resolved issues are deployed in test server so our client can review them.

we found this is very collaborative and simple. more over it has less overhead to manage. it is so visual that daily (end of the day) reporting is not restricted to any specific person. anyone can do it.

best wishes,

Reposted on my company blog

(agilebd) how are we adopting agile in our companies?

Hi,
thanks for initiating this thread, i will write about my experience on adopting agile.
this is my second company where we are in a transition from waterfall project management to agile based project management.
as you guys can pretend we have so many things to put together to make it easy to understand to those who none believers.

i am very very happy because of the positive and more agile attitude from management bench.
more over management has realized we have to be more picky while choosing client.
fortunately tekSymmetry (our company) is working with those clients who really love us seeing our open collaboration, more friendly attitude and honesty.

our belief is, “we don’t think client as our client we rather think them as our partner” we assist them to get smile on their face at the same time they are helping us to be happy being with them.

to help or accelerate adopting agile we had to do the following stuffs

- after stand up meeting we submitted daily (when sprint is running) “sprint burndown chart” and “sprint backlogs” to the management (management got more curiosity seeing more communication and transparent activities with in the development)

- simplified deployment process, (didn’t setup CI because we wanted more controlled environment, specially i wanted to understand the team and team attitude first)

- initially i had to prepare product backlog to demonstrate how to use it.

- joined with the development team and involved myself in coding

- understanding the development team and management team very closely to figure out how you can be part of their achievement. (thanks to  management because they rather helped me a lot and made so many things easier for us)

- my personal preference is “no give up policy, all human beings are similar possibilities”, i have been working closely and motivating each and every team members.

- helping them to understand they are not away from the standard and smartness.

- initiated “after sprint technical session”, (our talents prepare their presentation and present them to everyone, perhaps someday we will invite audience form many of your companies)

- ran 6 sprints being scrum master, showed them how to manage sprint backlog, how to keep it up to date, available time commitment and daily stand up

- built new scrum master who is now facilitating the core division of the team (we separate the team in two major divisions, core team, new feature team)

- helping him to realize scrum master is not someone who command, rather who “listen and suggest” with soft voice. more preciously he has to eradicate all those blocking issues which interrupting the team.

usually we keep the following stuffs on our scrum

- generally (8 development days, 1 sprint planning and 1 sprint review meeting) = 10 days

- bug fixing sprints are usually 1 week span (4 days work + 2 meeting) = 6 days

- retrospective meeting is organized after sprint review meeting, we used to go for lunch with the team to discuss about “what wasn’t good, could be improved”

- scrum team consists of developers + testers/qa + (soon we will add up designer too)

- test cases are prepared and delivered before any developer take commitment on any feature (though sometimes we can’t get everything before we kick starts coding)

- developer don’t practice test driven development rather they practice “validation driven development” (VDD _))

- i have practiced feature driven release on my previous company

- here we are practicing timely and feature driven release on new company (not yet released anything)

challenge i have faced

- motivating and showing team members their own career path

- helping team to understand the agile way instead of liner way

- making continuous productivity and hyperactivity understandable

- cutting the last moment hero rather making the team as a whole as hero

advantages i have found

- both of the companies where i have introduced agile, (somewhere in… and tekSymmetry) from management perspective view they had agile mindset

- management values human over process

- management is picky about choosing the right client with similar mindset.

btw, feeling constant headache, perhaps that is the reason beyond this
big email _)

best wishes,

this email was sent and published under agilebd (bangladesh agile) group

Scrum: How to understand stand up and burn down is effective ?

Scrum burn down chart and daily stand up meeting are the most important part of the scrum process to keep the team on focus. Scrum is good on bring transparency in development process. With utilizing better engineering practice like test driven development, continuous integration we could keep our productivity and fun on the same line.

If you are one of those  people who are wondering

What is called “stand up”?

I have a brief for you.

scrum stand up meeting

On the picture you could see, there are few people who are standing up and discussing about the following 3 topics -

1. What i have done yesterday!
2. What i will do today!
3. Where i have been stucking!

This is a required daily meeting where 10 minutes are spent together with all team members, this meeting is used to adjust the tasks among the team members also to monitor the current status.

Later this meeting is followed by a burn down chart which is attach on the wall or send through email to everyone or upload on some place which is visible to everyone.

scrum burn down chart

What is burn down chart ?

Burn down chart is a graph which is used to visualize how much hours work is left in an iteration (sprint). on the illustration you’d see a white line which is visualizing average burning hours per day. If we have planned for 180 hours tasks for whole iteration. Average burning hours should be minimum 180 / 8 days (if you have 8 days span sprint) = 22.5 hours to keep us on target.

The green line is visualizing the real team progress, you see this is not always up to the base line. It is moving up and down thus we are determining how the team is performing. If this green line is too upwards from the base line it means we are behind the schedule if that goes far below from the base line that reflects bad planning.

How to understand your team is understanding them?

I found the following symptoms to understand that our team members are understanding the importance -

• Everyone attending daily stand up on time.
• Everyone feeling responsible and notifying before they get late in office.
• Everyone eagerly reporting their status and taking commitment for today
• Team members are feeling guilty if some of them didn’t complete the commitment
• Everyone eagerly waiting to see the change in burn down chart
• If burn down shows some upward progress everyone get concerns and work hard
• Everyone feeling proud of the progress which shows in burn down.
• Everyone working every day not waiting for last moments push.
• Everyone keeping their daily commitments
• When burn down curve is  not moving too upward or not falling too downwards.

Most important change in scrum is your team doesn’t need to work over night or over weekend to keep progress around the base line. (i will later discuss about how iterative and incremental planning can help). Fortunately we have discovered these changes on our current team.

The most important thing is feeling the “team way” which we are missing in most of our teams, I guess utilizing the tools and process like scrum that can be improved a lot.

best wishes,