Posts Tagged ‘agile’
You would probably not associate a god from the Indian pantheon with an Agile methodological, and there are many things that can be learned for Scrum masters from Ganesh.
In Scrum the Scrum Master focuses on 4 key areas:
- remove impediments
- buffer against distracting influences
- enforcer of rules
- focusing team on tasks
Ganesha is the Lord of Obstacles, both material and spiritually. And is worshiped as the remover of obstacles, although he also places obstacles in the path of worshipers. The Scrum Master also removes the impediments and places obstacles in the path of the team members. Ganesha fans his ears constantly to symbolize that often words are spoken, but one is not receiving inside. This is what happens when the length of the meetings is too long, or it digresses off-topic. This is also what the broken tusk is said to symbolize, with oneness of mind and single-minded devotion you can achieve everything. In your team you can keep your focus by focussing the energies on the ability of the team to create results, and allowing the members to achieve.
Image source: Vijay Bandari – Wikipedia, Anamika S
After reading about 2 pizza teams in Wired UK 03.12, I read that the comment came from Werner Vogels, the Amazon CTO. He says prefers two-pizza teams; “technology teams working on a given project typically can be fed by no more than two pizzas—usually eight or fewer people.” This makes no sense to me, and I’m sure you may find the same.
I can easily eat a 13″ pizza at one sitting. A 13″ pizza has an area of approximately 856.3 cm2, the largest size that Dominos Pizza makes is 16″ with an area of approximately 1297 cm2. This means that I would be full at approximately 66% of the 16″ pizza, when I split it evenly the pizza only feeds two and leaves us both a little hungry.
How does Vogels think he can feed up to 8 people with 2 pizzas?
Image source: VirtualErn
Everybody tells you not to reinvent the wheel, and I am going to explain why everybody is wrong and you should start re-inventing. Programming paradigms and design patterns are the staple of all new programmers, and they enable everybody to communicate in a common language which can be easily understood when their rules are strictly adhered to. The issue is that beginner developers have cursory knowledge, expertise and familiarity with the design patterns they are required to implement.
A recent practical example a group of relatively inexperienced programmers with the Model-View-Controller paradigm found that the controller they were using didn’t make their life easier, so in some specific cases they deviated from this and implemented their own heuristics. This caused the underlying database to get more SQL queries that even Facebook reports it gets. At the point the website ground to a halt a simple investigation revealed that they bypassed the controller and model to access the database. Common heuristics would usually point to scaling vertically or horizontally.
If it looks like a duck, it walks like a duck, and it quacks like a duck, guess what? It’s a duck.
It is not always a duck. Current thinking is that common things are common, and common problems have common solutions. This isn’t always the case, Henry Ford summed it up best: “If I had asked people what they wanted,” he said, “they would have said a faster horse.” By living in the constraints of their knowledge when people hear hoofbeats, they think horses, not zebras. And “[w]hen faced with a result that doesn’t go according to plan, a series of perfectly effective short-term tactics are used until the desired outcome is achieved.” Some developers believe that once this hurdle has been taken all will be well, I can tell you the light at the end of the tunnel is an oncoming train.
When you are in a hole, stop digging! That is exactly how we got into the mess in the first place.
How do you stop digging?
You have become increasingly convinced of the truth of your misjudgment, developing a psychological commitment to it. You have become wedded to this distorted conclusion. Realizing this is your first victory. “In the material world, the unknown is a place of uncertainty and potential risk … [b]ut we make a mistake when we attribute the same qualities to the world of our thinking.” The second victory is having the courage to throw out everything you have done up to now, baby and bathwater.
“There is a wonderful story of a group of American car executives who went to Japan to see a Japanese assembly line. At the end of the line, the doors were put on the hinges, the same as in America. But something was missing. In the United States, a line worker would take a rubber mallet and tap the edges of the door to ensure that it fit perfectly. In Japan, that job didn’t seem to exist. Confused, the American auto executives asked at what point they made sure the door fit perfectly. Their Japanese guide looked at them and smiled sheepishly. “We make sure it fits when we design it.” In the Japanese auto plant, they didn’t examine the problem and accumulate data to figure out the best solution—they engineered the outcome they wanted from the beginning. If they didn’t achieve their desired outcome, they understood it was because of a decision they made at the start of the process.”
Starting with a clean slate learn to question everything you know and are told, especially what I tell you. Learned heuristics can be good, but they are only as good as your teacher. You own experience is key to be able to implement anything. Having a prototype or an example can help you, and a prototype is only as good as the developer who wrote it. Don’t be afraid to start over rather than refactoring, there is little to lose and everything to gain by ignoring the old paradigm: “If it ain’t broke, don’t fix it.“
- How Doctors Think – Jerome Groopman, MD
- Start with Why – Simon Sinek
- Effortless Evolution – Jamie Smart
- Wall Street proverb
Image source: Sebastian Fritzon
Signals come from everywhere, they are tell us something about our environment. Whether it’s hot or cold, wet or dry, and painful or pleasant. These signals are rarely binary, there are gradients in the signals. And we have signals with which we aren’t dealing at that moment, which we’ll call noise in that instance. Feedback is also a signal, perhaps it causes a painful sensation or it causes a pleasant sensation. Whatever the sensation it causes that sensation too is another signal which we can choose to regard as noise.
I like a User Story to be precise and target a specific functionality, a Use Case or a logical vertical of a Use Case. This means that a finely scoped task of 2 or 3 hours could be called small. It also depends at what time in the SCRUM backlog a certain User Story is implemented for it to be a small or large User Story.
At the beginning of any development project all User Stories are large, they include many additional variables everything from setting up the initial design patterns, to drastic refactoring to allow for stackable functionality. This means that a task which might take 2/3 hours once there is a working vertical to build on could take considerably longer when everything needs to be build from scratch. Ron Jeffries – SCRUM God – says Read the rest of this entry »
Recently I was asked by a client to make some estimations regarding a review of a code review for a programming project. The aim of the project is to refactor the existing code for efficiency, check the security and add new functionality. Having done code reviews in the past I had an idea on how it should be done, and little idea on how to quantify the work into an estimate.
How a code review estimate is done now?
Testers are very important in SCRUM, before the sprint they help the Product Owner to refine the User Stories are help with “How to Demo” and “Definition of Done”. Doing this during backlog grooming or analysis meetings allows the Testers to suggest User Stories for testing such as in the sidebar, and allows them to product examples which can be used for automated testing, help with sprint planning, among others.
“As a Tester, I want to read a log, so that I can verify that payments have been processed”
During the sprint, while programmers will be implementing the functionality, the testers will be implementing manual test scripts, automated tests and acceptance tests associated with the user story. In some places they develop the automated tests paired with a programmer, and in others they script the tests themselves. The testers would deliver “Running Tested Features”, preferably together with the programmer, which comply with the Definition of Done which the Product Owner, Testers and Team have defined.
You can see that Testers are a vital part of any SCRUM team.
Image source: Wikipedia
Sources: Lance Walton, Henrik Kniberg
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?
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.
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.