hasan's blog (বল্গ)

_), Suddenly this topic came out, i think it is one of the important
issues to keep sprint task simple and easy to accomplish and
estimate.

i was about to write this sprint backlog task for my pet project
(http://welltreat.us)

“Email notification should include review content Or comment content”

so while i was writing it down, suddenly this thing poped up!, how
about if i break it down and accomplish part by part, since
technically it states two tasks in one sentence. also more preciously
i can’t work on the different tasks at the same time.

so, if you break it down you might see the following tasks -

1. Review notification email should have user’s review content

2. Comment notification email should have user’s comment content

Now it came up with more implementable units.
from my personal observation, i found breaking down task to very small
implementable units make it very easy to discuss, implement as well as
test.

moreover usually very small unit of task is easy to implement a day,
which gives developer better satisfaction. because you have completed
some tasks.

psychologically it helps to build confidence and GUT on the their
ownself, which is very important to keep their motivation level high
to bring coolness and WOWness with in the team.

already posted in agile bangladesh group

best wishes,
see you guys in ruby on rails seminar on 13th (10 am) at basis
conference room _)

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,

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.

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 -

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

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 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,

hi,
just jotting down all my thoughts what we partially discussed today at coffee with sqabd session.

why unit test (a developer perspective) ?

when we (developer) code we need to spit out some information to verify certain point of function/logic to ensure they are returning or working as the way they suppose to behave.

for example –
def convert_to_taka(p_dollar)
  return p_dollar * get_current_taka_conversion_rate()
end

def get_current_taka_conversion_rate
  # let’s say, this function retrieve this value from remote web service call
end
as you can see “convert_to_taka” function is not all in all, it has dependency to another method where it delegates it responsibility to get the current currency rate for taka.

so as a developer my responsibility is not only to ensure convert_to_taka method also my responsibilities include to verify whether get_current_taka_conversion_rate is behaving properly.

so before i was introduced with test first approach. i used to write my code in the following manner -
def convert_to_taka(p_dollar)
  logger.debug(“converting dollar #{p_dollar} to taka”)
  conversion_rate = get_current_taka_conversion_rate()
  logger.debug(“conversion rate for taka – #{conversion_rate}”)
  return p_dollar * conversion_rate
end
so during my development process i had to watch these logging outputs with my eagle eyes so that nothing could get out my concern.

why test first development ?

as you can understand from the “test first development approach”, it reflects something has to be upfront.
without developing we can’t test what is going to be developed, but using test first approach it means you are preparing your expectation upfront to get your code working with your expectation. so here what i would have written if i knew test first approach before.

def setup
  # mock currency retrieval web service or whatever requires to set 70
  # as the returnable value from get_current_taka_conversion_rate()
end

def test_should_successfully_convert_currency_with_valid_input
  assert_equal(7000, convert_to_taka(100))
  assert_equal(525, convert_to_taka(7.5))
end

similarly you could have the following test cases
def test_should_fail_to_convert_currency_when_webservice_returns_error; end
def test_should_fail_to_convert_currency_with_negative_value; end

so if you compare this with the above statement where i mentioned “logger.debug” related stuffs.
you can see the difference where this one is more understandable for us to re imagine what our task means to us.
this approach would give us chance to rethink about the task we have chosen (if agile team).

why it has nothing to do with tester test ?

test driven development is for developer to do his/her job properly to ensure better code (less bug) according to his task definition
eg. user stories
as a developer
i want to see my function is working while currency web service is not returning anything

or perhaps

as a developer
i want to see my function is taking last known currency exchange rate from cache data while currency web service is failing.
or perhaps

as a visitor
i want to convert my currency by clicking on “convert currency” button

or

as a visitor
i want to convert my currency without refreshing the whole page….

this has nothing to do with 1px design issue, or notification message doesn’t appear immediately or problem from user kinda tester point of view. still we need them badly to bet on burger per bug

so i think i could make sense why it won’t worth anything if tester prepare the test case for developer :p

TDD is to verify our own code
(because client changed his mind, or because we need to support another scenario)

when requirement changes or adds new scope, we have to review our own code to enhance the scope.
here comes compatibility issue, as you can understand old test cases would become the more kissable asset to verify our recently modified code against the old requirements and new requirements. (perhaps some function requires old way to do the job)

TDD is enabling us to run continuous integration and build process

as you can recall what sajjad bhai was mentioning about continuous integration and warning for those (developer) who break the code.
using these developer created test cases we can do this job.
or perhaps we can employ our testers (hardly a few) those who LOVE (or forced to love) to write integration test case.

anyway, thanks for nice afternoon with mouth watering pizza and coffee, wish to see more pizza slices
best wishes,