Originality?
Schoolgirls on a trip to visit the great buddha at Nara
Hats hanging up outside the classroom at another school
Uniforms and uniform backpacks, lunches, school supplies.
Everyone carries an umbrella
11/8/13
Observations on Japanese culture - Part 4 - Uniformity
Originality?
Schoolgirls on a trip to visit the great buddha at Nara
Hats hanging up outside the classroom at another school
Uniforms and uniform backpacks, lunches, school supplies.
Everyone carries an umbrella
Agile Project Management Tips #9: Keep a Project Diary
Keeping a log of activities is not a new idea. Projects were tracked when Stone Age people drew pictures of a hunt on cave walls. Most tracking consists of structured metrics used to show managers and executives that the project is on target for the impending future release. Keeping a diary, however, is a way to track where the project has been.
A daily diary, like a personal diary, is meant for your eyes, and should be written for you as the audience. It can contain many bits of information that might not incorporate well into the project process. For example, if you have a complicated email exchange, do not leave it in your email client. Spend time extracting the exchange into paragraphs and annotate with pertinent details. Paste everything into the diary, and date it. Later, when someone asks, “What were we thinking at the time?” the diary will act as a personal reference to jog your memory.
Another use of a diary is to note exceptional efforts by team members. If someone on the team has a shining moment, make a note of it in your project diary. For supervisory staff who write employee performance reviews or provide feedback to Human Resources for employee assessments, these examples in the diary will prevent a lot of head scratching later and will benefit everyone.
Some activities to write down are
- Hallway Conversations
- Complex email threads
- Reasons for decisions
- Exceptional efforts by team members
- Gut feelings or intuitions about the project
The benefits are
- Helps answer the question "What were we thinking at the time?"
- During retrospectives, the diary can help you prepare your notes.
- Helps if you have to contribute toward employee evaluations
- Provides a "long tail", some thing to give you a history
Most importantly, the project diary is a way to provide a history for you. After many projects, you may wonder what you have accomplished, and how you got there. Since the diary entries were personal for you, you can include ideas, guesses, feelings and emotions among the timeline and events. Years later, when you recognize a situation, the project diary provides a reference, of not only how the situation was handled, but also your thoughts at the time.
Introduction
Agile Project Management Tips #8: Increase Communication by Pairing
Many Scrum proponents endorse creating cross-functional teams, but they do not always describe in detail the team mechanics. The high-level description is usually something like “Scrum relies on a self-organizing, cross-functional team. The Scrum team is self-organizing in that there is no overall team leader who decides which person will do which task or how a problem will be solved.” (see Cohn, What is Scrum Methodology?) As a result, team members may end up creating their own personal silos, with developers writing code, testers checking it, the business analyst reviewing, all without collaboration. Consequently, the hand-off points become discrete, and the communication between team members is limited.
Similar to cross-functionality, many Agile evangelists also point to pair programming as a way to create better code with fewer bugs than when programmers work alone. But, why limit pairing to only developers? By pairing developers with testers or testers with the technical writer, or the business analyst with the developer, you can achieve benefits similar to pair programming for the entire team.
For example, we occasionally have the developer write the rough draft of the user documentation. This process helps the developer better understand the user workflows and often uncovers gaps in functionality. Moreover, as the technical writer sees early versions of the system, he can look at it from the point of view of documenting user workflow and suggest changes to the UI to improve usability.
In the same way, asking a developer to sit with the tester while creating the initial test plan increases the informational bandwidth between them. The developer can point out areas that may need more scrutiny or were touched in development but not obviously connected to the main functions of the code. And, the tester may notice areas where the developer may not have fully understood the implementation of a feature. As they create the test plan, the developer may recognize that the tester is not working with the same mindset and steps that he assumed while writing the code.
These pairings are a great way to shorten the loop. Throughout the development process, the goal of the Scrum framework is to increase participation, ideas, and the general quality of the product through shortened feedback loops. This means each minor iteration of the process should have feedback, and meeting face to face is the best way to accomplish this.
Managers and Scrum Masters can do the following to make pairing sessions successful:
Similar to cross-functionality, many Agile evangelists also point to pair programming as a way to create better code with fewer bugs than when programmers work alone. But, why limit pairing to only developers? By pairing developers with testers or testers with the technical writer, or the business analyst with the developer, you can achieve benefits similar to pair programming for the entire team.
For example, we occasionally have the developer write the rough draft of the user documentation. This process helps the developer better understand the user workflows and often uncovers gaps in functionality. Moreover, as the technical writer sees early versions of the system, he can look at it from the point of view of documenting user workflow and suggest changes to the UI to improve usability.
In the same way, asking a developer to sit with the tester while creating the initial test plan increases the informational bandwidth between them. The developer can point out areas that may need more scrutiny or were touched in development but not obviously connected to the main functions of the code. And, the tester may notice areas where the developer may not have fully understood the implementation of a feature. As they create the test plan, the developer may recognize that the tester is not working with the same mindset and steps that he assumed while writing the code.
These pairings are a great way to shorten the loop. Throughout the development process, the goal of the Scrum framework is to increase participation, ideas, and the general quality of the product through shortened feedback loops. This means each minor iteration of the process should have feedback, and meeting face to face is the best way to accomplish this.
Managers and Scrum Masters can do the following to make pairing sessions successful:
- Make sure that the team has time to pair and suggest including pairings as tasks attached to stories. This raises the visibility of the pairings and allocates the time.
- Ensure that both sides get encouragement. Developers like to show off their code, but can be protective of it. If the interaction is confrontational, it will not work and will not become a habit. The Scrum Master should plan to attend the first couple pairings and encourage a positive outcome.
- Keep the sessions concise. When working on complex problems, pair programming and other types of pairing is useful, but difficult. It is two different minds working together on the same problem and sometimes people pull in different directions. Set aside time for the pairing, but avoid forcing the issue. Let the team self-organize.
Agile Project Management Tips #7: Simplify Design with Paper Prototypes
Requirements people, designers, and developers think on different levels. When they meet to plan what needs to be done they focus on different aspects of the specifications rather than on the problem that needs to be solved.
One way to avoid this is to embrace paper prototypes. When the team goes to work on a screen design, the fastest way to get everyone’s participation is to use paper, markers, scissors and tape or glue stick. In a just a few minutes, one team member can sketch out an initial screen and then let others add to the work. Using black markers enforces simple screen design and removes colors and fonts from the equation. If people make mistakes or suggest changes, tape and scissors make it easy to rearrange the screen. A photocopier can be used to duplicate parts if necessary.
Working interactively on the page turns it into a shared design problem. Everyone in the team can participate in naming items, and the business analyst can remind the team of the real-world terms. Once the prototype takes shape, testers can apply their tests to the paper: How many characters? Is this required? Where do you go when you click on this?
Paper prototyping has been used for years, and it continues to be useful in this age of mobile devices. Whether you are designing a screen for a tablet, a smart phone, or a computer, the basic rules are the same. Using a paper model makes initial design easier. Print out an oversize template of an iPhone, photocopy it, and then use that to draw in the screens with markers. To replicate the user experience, you can stack up the pages, hold them in your hand like a phone, and then flip through the story.
Working interactively on the page turns it into a shared design problem. Everyone in the team can participate in naming items, and the business analyst can remind the team of the real-world terms. Once the prototype takes shape, testers can apply their tests to the paper: How many characters? Is this required? Where do you go when you click on this?
Agile Project Management Tips #6: Draw Out Ideas
Reviewing architecture and design documents can be tedious and boring since the process is passive: sitting in meetings trying to evaluate someone else’s design work. Participants easily check out, often keeping their eyes and hands occupied by doodling in their notebooks while the meeting uses their ears and brain.
Drawing, however, is an excellent approach to engage the brain in multiple ways, making a more creative and memorable meeting for everyone. A recent Wall Street Journal article began “Employees at a range of businesses are being encouraged by their companies to doodle their ideas and draw diagrams to explain complicated concepts to colleagues.” Drawing can be used to promote engagement, visual thinking, and enhance note taking.
I used to prepare diagrams or schema using Visio and hand them out in meetings only to realize that people were not fully engaged. I had gone through the journey of creating the visual, but for everyone else it was just a static image. Looking at a picture can be a fleeting event and the less energy one puts into it, the less memorable it will be.
In design meetings now, however, I arrive with an image in my head, and make sure I have a space to draw it out. The process is more engaging and we share the journey as the drawing is created. Describing the design and drawing it out simultaneously combines two methods of learning, sight and sound, helping to reinforce the ideas. The technique has many benefits.
is an excellent book that provides a variety of ways to make meetings more dynamic and participatory with graphics and drawing.
In addition to using drawing in meetings, drawing helps with other parts of the design process. Kevin Cheng, author of See What I Mean
promotes the idea of drawing comics for business reasons. Creating storyboards and scenarios as comics not only engages people in the process, but also saves time and effort. The sequential comic frames are simply another way to represent the steps in the user stories. Drawings can also be used to visualize the user experience, which is the main idea behind his web comic “OK/Cancel.”
Save the drawings at least until the end of the project. Even when working on a whiteboard you can still take a photo of the board and the memory of drawing it will stay with people.
Drawing, however, is an excellent approach to engage the brain in multiple ways, making a more creative and memorable meeting for everyone. A recent Wall Street Journal article began “Employees at a range of businesses are being encouraged by their companies to doodle their ideas and draw diagrams to explain complicated concepts to colleagues.” Drawing can be used to promote engagement, visual thinking, and enhance note taking.
I used to prepare diagrams or schema using Visio and hand them out in meetings only to realize that people were not fully engaged. I had gone through the journey of creating the visual, but for everyone else it was just a static image. Looking at a picture can be a fleeting event and the less energy one puts into it, the less memorable it will be.
- Telling stories while drawing helps people who learn using different styles. Drawing is a process and a result, your mind carves out the lines as you examine the subject.
- The images will transcend language: drawing out ideas works even when colleagues do not share a common first language or have the same level of technical understanding.
- Drawing is participatory: The brainstorm is directed and scoped, but democratic. Others may draw on the board or paper as well. It helps foster involvement in the critical thinking process, whereas a completed and polished image may give the impression that it is beyond criticism.
- Drawing brings out creativity. As the cartoonist Lynda Barry
says about her graphic memoir/how-to book What It Is
, “drawing or expressing your image is a therapeutic biological change that occurs in your body and makes you say ‘ah!’”
- Studies have shown that drawing enhances retention. In Moonwalking with Einstein
, Jonathan Foer devotes a chapter to discussing mind maps and how they correlate with memory palaces (Foer 2011). A memory palace is a visual mnemonic device used to help organize and recollect bits of information. As the team works with the image, they inadvertently create spatial memory palaces of the system in their minds. Later, when writing code or testing, the image can help clarify details and provide a context within the larger system.
is an excellent book that provides a variety of ways to make meetings more dynamic and participatory with graphics and drawing.In addition to using drawing in meetings, drawing helps with other parts of the design process. Kevin Cheng, author of See What I Mean
promotes the idea of drawing comics for business reasons. Creating storyboards and scenarios as comics not only engages people in the process, but also saves time and effort. The sequential comic frames are simply another way to represent the steps in the user stories. Drawings can also be used to visualize the user experience, which is the main idea behind his web comic “OK/Cancel.”Save the drawings at least until the end of the project. Even when working on a whiteboard you can still take a photo of the board and the memory of drawing it will stay with people.
11/6/13
Agile Project Management Tips #5: Broadcast with Information Radiators
Information radiators are one of the best low-tech devices for broadcasting the status of a project. Since they are visibly posted, it is a passive process. No one has to seek out the status or refresh a web page. As Cockburn mentions “online files and web pages generally do not make good information radiators, because an information radiator needs to be visible without significant effort on the part of the viewer.”
Our information radiator shows:
- The current sprint’s stories and related tasks
- A Kanban-style board with work under progress
- The current build number and timestamp
- The most recent release number and timestamp
- All the stories from the product backlog
- A graphical display of the number of tests planned versus passing
- Any planned resolutions discussed during the most recent sprint review
- The status of any of the team members if they will be on vacation or otherwise unavailable
 |
| Information radiator showing product backlog and retrospective of previous release |
Fortunately, we overcame those problems. Instead of a whiteboard, we used the cubicle walls for posting the backlog. Since it was difficult to get sticky notes to adhere to fuzzy cubicle walls, putting a long piece of strapping tape on the cubicles made a non-porous surface that worked better. The development area lacked space to display everything together, so we compromised by posting the backlog in one area, and the sprint status items in a slightly different area, but still visible from one spot. Moreover, passing traffic increased when sales materials were stored in an area just past development. Now the sales and training staff pass by the information radiator on a daily basis. Recently I saw a sales person looking at the cards, understanding what we are working on.
The biggest benefit of the information radiator is for the team itself. It creates a sense of completion as the backlog whittles down, and the sight of a once-daunting project dwindling down to a small tail of outstanding stories is a sure morale booster.
The Agile Alliance has more about information radiators here.
<< Previous Tip
Next Tip >>
Agile Project Management Tips #4: Keep the Sizes Relative
In Scrum, the product backlog shows the amount of estimated effort required to deliver each story. While there are other methods of estimating, such as Mike Cohn's Planning Poker, T-Shirt sizing is a simpler way to get a baseline idea of effort. The human brain is better at estimating relative sizes than absolute sizes. Relative sizing is simpler since less information is required. Team members need only to recognize which stories are larger than others. The goal is to give the stories T-Shirt sizes (XL, L, M, S, and XS) relative to each other. Then, after several iterations of tracking the stories completed in a sprint, the team will have a better idea of the schedule for the remaining stories.
A problem, however, is introduced when some team members try to correlate relative sizes with absolute amounts, such as “S = one day”, while others may use a different scale. Workdays are a subjective unit of measure and depending on other commitments, ideal days will vary. Using a simple mechanical method avoids this problem.
Only the Scrum team participates in the sizing process. Team members arrive at a sizing session with an idea of the stories and with any information that might inform their estimates.
The sizing process is similar to the one described above for prioritizing stories, except the Scrum Master leads the session. After an arbitrary story card is placed on the wall, the Scrum Master pulls the next card, reads it aloud, and asks if people think this story is larger, smaller, or about the same size as the one the wall. The vertical axis represents the size of the stories with higher on the wall indicating more effort; lower on the wall is less effort. People in the meeting say “higher” or “lower” and the Scrum Master follows their suggestions. If the team cannot agree on the size, then it is open for a five-minute discussion, and the Scrum Master decides the final position.
After all the stories have been placed on the wall relative to each other, divide the wall into five equal vertical sections. Mark the sections XL, L, M, S and XS, respectively. Drawing the five sections is a physical method for categorizing the stories by size.
Sizing the stories this way creates a visual map of the project in terms of effort. Reviewing it may highlight red flags hidden in the project. The Scrum Master should watch for L and XL stories that have lower priorities; in the last third of the project, for example. Large and XL stories toward the end of a project represent riskier work. Software projects have enough uncertainty that teams will want to avoid planning large stories at the end of a project. The PO may want to think about raising their priority, dropping them from the project, or trying to break them into smaller features.
Since the stories sizes are relative, the majority of the stories should fall into the small, medium and large categories. If there is a larger ratio of XL stories then the team should re-examine the stories that fall between L and XL. Perhaps the team has overlooked some details of the stories, or perhaps they are epics that should be split into multiple, smaller stories.
Note: relative sizing only works for stories considered during the same session, but the simplicity of the process makes it especially accessible for teams and team members who are new to Scrum.
<< Previous Tip
Next Tip >>
A problem, however, is introduced when some team members try to correlate relative sizes with absolute amounts, such as “S = one day”, while others may use a different scale. Workdays are a subjective unit of measure and depending on other commitments, ideal days will vary. Using a simple mechanical method avoids this problem.
Only the Scrum team participates in the sizing process. Team members arrive at a sizing session with an idea of the stories and with any information that might inform their estimates.
The sizing process is similar to the one described above for prioritizing stories, except the Scrum Master leads the session. After an arbitrary story card is placed on the wall, the Scrum Master pulls the next card, reads it aloud, and asks if people think this story is larger, smaller, or about the same size as the one the wall. The vertical axis represents the size of the stories with higher on the wall indicating more effort; lower on the wall is less effort. People in the meeting say “higher” or “lower” and the Scrum Master follows their suggestions. If the team cannot agree on the size, then it is open for a five-minute discussion, and the Scrum Master decides the final position.
After all the stories have been placed on the wall relative to each other, divide the wall into five equal vertical sections. Mark the sections XL, L, M, S and XS, respectively. Drawing the five sections is a physical method for categorizing the stories by size.
Sizing the stories this way creates a visual map of the project in terms of effort. Reviewing it may highlight red flags hidden in the project. The Scrum Master should watch for L and XL stories that have lower priorities; in the last third of the project, for example. Large and XL stories toward the end of a project represent riskier work. Software projects have enough uncertainty that teams will want to avoid planning large stories at the end of a project. The PO may want to think about raising their priority, dropping them from the project, or trying to break them into smaller features.
Since the stories sizes are relative, the majority of the stories should fall into the small, medium and large categories. If there is a larger ratio of XL stories then the team should re-examine the stories that fall between L and XL. Perhaps the team has overlooked some details of the stories, or perhaps they are epics that should be split into multiple, smaller stories.
Note: relative sizing only works for stories considered during the same session, but the simplicity of the process makes it especially accessible for teams and team members who are new to Scrum.
<< Previous Tip
Next Tip >>
Subscribe to:
Posts (Atom)