recentpopularlog in


« earlier   
Reality Driven Development: Fixing Project Management in Software | Brightball, Inc
Ever since my first project management class in grad school, it just made sense to me...but after about 15 years in software it doesn't anymore. Let me explain how to fix it.
agile  management  scrum  kanban  projectmanagement  bestpractices 
2 hours ago by shrike
A guide to agile communication - Guidance
who do you want to influence? What do you want them to know or understand that they didn't already? What's the best way to communicate with those people?
Agile  from iphone
yesterday by miaridge
Agile UX: It’s Not as Bad As You Think User Experience Magazine
Agile is an approach to doing work—any work, but especially complex work—that emphasizes transparency, trust, honesty, and collaboration. It places a strong emphasis on delighting, and interacting with, our users. And while Agile does encourage short feedback loops, it definitely does not ask us to compromise quality in order to achieve them. Those short feedback loops are intended to help us get quick insights from our users so that we can continue to iterate until we meet or exceed their expectations.
Our Experience

Our team, three UXers, two architects, a manager, and an Agile coach, was designed to support the vision of the director of software development. He wanted to build and roll out a method for product development across the organization that was responsive to user needs, produced business results quicker and more effectively, and encouraged inclusion of colleagues from all areas of the development and product organizations. Because our team performs change management work and is necessary to the product development process, his approach was for us to work together on the initiative, rather than separately.

Except for the Agile coach, we had limited experience with Agile, but our manager had used this approach with different types of teams in the past and helped us see the opportunities. Being a servant leader, his approach was to expose us to the ideas, give us access to a coach, and then let us work together to figure out what would work best for us.

Our manager explained it this way:

“It was always our vision to bring together the true customer-first mentality of user experience experts with the technical forward-thinking of architects. We felt we could genuinely create collaboration between these two roles by utilizing Agile principles and that the results would yield an industry-leading experience for our customers.”

—Mike F, manager

We were not completely convinced but were willing to give it a try. Accordingly, we approached our Agile initiative as an experiment, forming a hypothesis and trying different things until we found something that worked.
Where Do I Start?

Our first step was to get off site for a day where we could be free of the distractions in the office. This approach really helped us open our minds to new and different ideas. We started the outing with a team retrospective, a meeting to discuss what was working, what wasn’t working, and to decide on next steps.

We covered the wall with sticky notes, calling out our pain points (see Figure 1). After some discussion, we managed to group them into three main areas:

The UX and architecture teams were not being included early in the product development process. This was leading to last-minute changes and a lack of attention to design and technical standards.
Our manager was being pulled in many directions, making it difficult for him to help team members grow as influential contributors within the organization.
We were placing little, if any, emphasis on developing our individual skills and collaborating with our colleagues within the organization.

Woman standing at a wall of sticky notes.

Figure 1: Our Agile coach helped the team work through priorities during our offsite retrospective activity.

After the retrospective, our Agile coach facilitated an Agile team self-assessment so that we could identify our current Agile fluency level. Not surprisingly, we scored ourselves as having little to no fluency with Agile, and struggled to understand how we might apply the techniques to our work.

We continued our discussion and chose a few Agile techniques that we thought might help us alleviate some of our pain points. Our Agile coach helped us understand which techniques might be good fits and why.

We decided to try out the techniques outlined in the following sections.
Team Name

Deciding on a name for your team might seem trivial, but it’s an especially effective way of helping teams start to see themselves as a single entity working together toward a common goal. We found that it was quite hard to find a team name that we all liked and that adequately captured our team’s personality, purpose, and situation within the greater company’s culture.

One day at a team lunch, one of our members threw out that we were like the “Misfit Toys” from the Rudolph the Red-Nosed Reindeer Christmas special. It fit because of our collection of skills, our placement “on an island” outside of the product development process, and our empathy and caring for users and our colleagues.
Physical Team Board
prioritized board with sticky notes noting tasks in order of status.

Figure 2: Our physical team board helped us engage in more meaningful conversations and helped us get our work done faster.

We were already using an electronic tool to manage our work but wanted to find a way to make all of our work more visible to our team members and ourselves. We were also trying to find a way to encourage richer conversation between team members and create transparency to the organization about the work we were doing. We started doing our daily stand-up meetings (see next section) at our physical board and noticed that they became more meaningful. We were getting work done more quickly and finding ways to help each other.
Daily Stand-Up Meetings
A man and a woman stand at the status board discussing the work.

Figure 3. The team met at the physical board every morning for stand-ups up that helped us work better as a team.

Daily stand-up meetings are a common Agile practice that comes from the Scrum framework. The concept is that the team meets briefly once a day, typically in the morning, so that each team member can share what they’re working on that day and what, if anything, is blocking their work. The stand-up helped us get to completion faster, better understand each other’s work and blockers, and function more like a team solving problems together as opposed to individuals working in isolation.
Sprints (aka Iterations)

The concept of a sprint also comes from Scrum. A sprint is a timebox of one month or less (the shorter the better) in which work is “pulled in” by the team and completed. In development teams, completed or “done” often means working in production. For us, “done” meant we could demonstrate the work and it could be released to the greater organization. We found that using such a timebox helped us focus on the most valuable work and provided a tool to enhance our discipline around getting one thing done before starting another.

As a team with not enough people and more work than we could possibly do, one week-long sprint helped us get out of the overwhelmed frame of mind and into one where we could get things done and have a sense of accomplishment. It also provided a tool for communicating with stakeholders about what we were doing and when they could expect our assistance.

The struggle with short timeboxes was that our team was unused to working on one small thing at a time. For us, the trick was to figure out how to break down large assignments—like user research—and design into several smaller, bite-sized chunks of work that could be completed one at a time in just a few days.

In the user research and design example, we might break the work down into chunks like this:

Interview users of one specific type and file the resulting data
Create a quick sketch based on the resulting data
Schedule a meeting to review resulting data with product and development and get feedback
Update sketches based on feedback from product and development
Create a recommendations document
Continue to test and design for another specific type of user

While choosing such a small sprint cadence might seem crazy, it was actually very useful. We found that with a shorter sprint cycle we could be more responsive to our partners on the development and product teams. The developers were working in three-week sprints and because we were not embedded in their teams, it had been hard for us to provide the support they needed in their sprint cadence. By choosing a shorter sprint cadence, we were able to easily pull in the work we needed to do for them with little notice and complete it before their sprint ended.

whiteboard text from an Agile retrospective.

Figure 4. One of our retrospectives resulted in a short list of things to try in the upcoming month: (1) Push to next month instead of “right now” (2) keep the [physical] board (3) delegate to team members (4) office hours (5) use the scrum master
We decided to perform a retrospective (see Figure 4) once every four weeks so that we could see how our Agile experiment was going and decide what to keep doing and what to do differently. We found that retrospectives gave us a chance to get out of the day-to-day grind and think about how to get better in both team- and craft-related topics. It was also a time for us to laugh and be ourselves, which made the events something we looked forward to.

Scrum Master

The scrum master is a member of the team who is primarily responsible for supporting the team’s Agile growth and removing blockers and distractions. The scrum master is a servant leader who leads through influence rather than authority. In practice, the scrum master often leads Agile ceremonies and coaches team members on Agile techniques.

We were not able to gain approval for a full-time scrum master, so we rotated some of the responsibilities between us and assigned others to our manager and Agile coach. We took turns being what we called the “Sprint Leader,” facilitating daily stand-ups, retrospectives, and other team ceremonies, while our manager handled coaching the product representatives, and our Agile coach helped us grow our Agile skills and mindset.

This approach helped us share the burden for a role that we felt was crucial to our success when we could not fill the position with one person. By rotating the … [more]
ux  ux:martin  agile  vhs:schatzinsel:change 
2 days ago by MicrowebOrg

Copy this bookmark:

to read