product development and management solutions Archives

Posts

On a chance bus ride down MLK to our Jama office a few months ago I happened to share a seat with a colleague in our Engineering Department, Bryant Syme. He had only been working for Jama for a few months and to be perfectly honest I hadn’t spoken to him much yet. We talked a lot about recent events in the office, but also talked about some of his previous work experiences. This is the first time I had ever heard about Mob Programming and the many potential benefits it can bring to a team of engineers. It planted the seed for me to introduce it to my own team and eventually start evangelizing it to the rest of our department.

What is it?

Mob Programming is a style of paired programming, but with the entire team involved instead of two developers. Every person involved in the story should be in the Mob Programming session and actively contributing, including Product Managers, DevOps and QA Engineers.

Think of Mob Programming as a tool for getting through larger, more obtuse stories and epics. The team will crowd around a single screen with one person driving and will talk through everything from acceptance criteria and design decisions, to implementation of the code and even test cases.

Mob Programming has many benefits:

Shared ownership over decisions.
Better quality code.
Ability to break through large tasks easily.
Team bonding through working together.
A great way to teach other team members various skills.

This style of work doesn’t need to be limited to programming. It could also be great to work on any project, from writing a document to planning for future work, to doing performance testing.

The tenets of Mob Programming

The main tenets of mob programming that everyone should follow are:

Use one keyboard and screen
Use a private room
Select a time keeper to rotate who is on the keyboard every 15 or 30 minutes.
Everyone gets time at the keyboard, even non-programmers.
Take a story from start to finish, or in other words: from planning to coding, to testing, to done.
Take breaks when you want.
A session should span an entire workday.

Each of these tenets are flexible and should be discussed with the group before starting. One thing I’ve had a lot of luck with so far is pausing the timer to do whiteboard planning, for instance. We also usually take however much time we need at the beginning of the session to sketch a rough plan of what we are going to do, in order to stay on task as people switch around.

One keyboard and screen

This allows the team to concentrate without the distraction of e-mail, chat applications or other work. Team members may come convinced that they will need to work on other activities since there won’t be enough to help with when they aren’t at the keyboard. I had such an encounter with one of my teammates who was certain that there would not be enough for him to do. You will need to remind them that this is not a normal meeting and that you need their full attention. In the case of my teammate, I conceded that he could bring his PC as long as he kept his attention on the task at hand. He agreed and ended up being so engaged that he rarely, if ever, looked at his own screen.

One rule you can bend here is that research on one screen can be boring for the team to watch and help with. This is an appropriate time for other team members to use their own PCs to help do research (as long as everyone is staying on task).

Use a private room

This moves the team to another space both physically and mentally, and also prevents outside distractions. Other teams should respect that you have shut the doors and should not interrupt you. But if you are interrupted, team members should volunteer to chat with that person outside of the room to allow others to keep working.

Rotate who is on the keyboard every 15 or 30 minutes

Decide on a good time interval at the beginning of the meeting. I recommend 15 or 30 minutes depending on how many people are in the group, but other time increments are also fine. I’ve found that a group of 4 or less people works best with 30 minute intervals, wheras 5 or more works best with 15 minute intervals. Its just enough time to get some work done, but also enough for everyone to rotate through in the large group.

Bring a timer with a loud alarm. I usually use the Clock App on my iPhone and turn the sound way up. When the alarm goes off, whoever is at the keyboard should immediately take their hands off and let the next person rotate in, even if they were in the middle of typing. The thing to remember here is that it’s not about one person working while the others watch, as it is about everyone working on the same thing. Whoever else rotates in should easily be able to pick up where the last one left off.

A clock that resets itself is also ideal, since you don’t want to forget to start the timer.

Everyone gets time at the keyboard, even non-programmers

Whoever is helping should have a chance at the keyboard, even if they are in a QA, PM or DevOps role. Remember that everyone is working on the same task and watching and directing what the driver is doing, and it should not matter much who is on the wheel. It’s ok to be a backseat driver in this situation.

Participation also keeps everyone at full attention! Keeping the same person or only developers will become boring for others in the room if they never get a chance to participate.

Take a story from start to finish

Even when coded, the story isn’t finished, it still needs to be tested! Work on your test cases as a team. Personally, I am a QA engineer and getting other team members to help work on making quality test cases is very validating and helps us be less black box.

Whatever is required to get that story into the “Done” column should be done during this session. In addition to getting higher quality code, test cases and automation, this also tears a lot of walls down between roles. A lot of our developers often don’t have much of an idea for what DevOps or QA engineers “do”. This is a perfect chance to get cross-team collaboration and boost how your team works together!

People are allowed to take breaks when they want

Bathroom breaks, coffee breaks, lunch breaks should not be discouraged, but be warned: people will want to keep working, so mandatory breaks may be needed!

Mob programming can also be exhausting, if someone needs a few minutes to take a breather, they should be allowed to simply leave and come back when needed.

A session should span an entire workday

This one has been difficult to schedule a lot of times. So far we have managed to schedule one full day and several half days of mob programming. Most literature I’ve seen on the topic so far recommends the full day, if possible, though. If individuals need to leave for meetings or other commitments, there should still be enough people left to absorb their absence.

Conclusion

Mob Programming is a great tool that can be used to effectively chop down and complete large stories and epics. Remember if you are trying this, review the tenets with your group, such as sticking to one screen and one keyboard, as much as possible.

This is also great for bringing other team members up-to-speed with certain design patterns or tools. Someone who never uses the command-line or has never dealt with a certain language before will likely get a chance to learn a lot.

Everyone in the room should be involved, don’t limit it to just programmers, or others will get bored and not be as engaged. Remember to invite everyone in your team to the session, including the Product Managers, QA and DevOps Engineers.

And of course remember to have fun! Odds are your team will have a blast and work just a little better together than before the experience.

If there’s a constant theme for VPs of Sales, it’s pressure. In times flush and lean, driven by forecasts definitive and dubious, sales teams are the shock absorbers and the turbo chargers that sustain and propel a company. Sales always has a journey mapped out, but it also always has to be prepared to reroute around unplanned obstructions.

Suffice it to say that maintaining this forward momentum is never not a challenge. But for VPs of Sales concerned with selling complex products and services, minimizing navigation errors is critical because much is at stake:

Tall tasks:

Shouldering responsibility for keeping projections and actual sales aligned. A key part of this responsibility: Understanding how current and future product capabilities align with customer needs so teams can accurately sell to expectations over time.
Providing valuable user insights to product team leaders to create solutions that help the product evolve.

Pressure points:

Lacking visibility into the reasons behind product changes, their causes and effects, and the resulting pros and cons for customers.
Being dependent on others to communicate product changes that affect sales’ strategy and tactics.
Lacking an efficient way to best provide sales and customer feedback to the product team.
Feeding critical sales input into an email, spreadsheet or document-based vortex where it goes unrecognized and unprioritized.

Burning desires:

To have a simple, accessible and intuitive overview of product development status in order to communicate new features as part of the sales process, and to easily be able to deliver customer insights back to the product team.

With Jama, VPs of Sales can turn hazardous “Wild Wild West” episodes into trailblazing “Bonanza” epics.

How so? You’re able to…

Ensure that your sales team stays involved in the product delivery process from start to finish.
Capture and share customer feedback.
Keep the organization aligned with the strategic goals of the project.
Communicate easily with the entire project team to get clarification and decisions made, regardless of location.

Read Game Changers Who Play to Win: Omnigon to see a real-world example of the ways Jama can help you stay in the loop and on track to meet targets.

Check out other ways Jama helps business and engineering teams get and stay aligned:

How Jama Helps Systems Engineers

How Jama Helps VPs of Product

How Jama Helps QA Leads

How Jama Helps Project Managers

How Jama Helps Business Analysts

How Jama Helps Product Managers

Stop chasing down documents in DOORS and focus on the items within them that matter.

For many years, IBM’s Rational DOORS (v.9) has been a widely adopted Requirements Management (RM) tool for teams working with high-compliance systems engineering programs. Because it’s often sold into the enterprise as part of a larger IBM suite, its widespread use is sometimes a matter of default rather than choice.

If you’re like most of today’s systems-driven engineering organizations, you’re primarily in the business of producing complex, ﬁnished products and components, often involving a mix of hardware, software and ﬁrmware. You’re probably also in a hybrid-Agile development environment and figuring out how to scale that effectively.

In business, times change because needs change. Changes driven by the rise in software-driven products, the imperatives of on-time delivery, and extended supply-chain systems threaten to disrupt traditional, legacy manufacturing and engineering processes. Your teams are pressured to accelerate product delivery and manage growing complexity in distributed organization and supply chains, within products, and across a network of interrelated and interdependent products.

Jama is built to serve and evolve with the ways systems engineering teams build products. How is it different? Jama deconstructs documents into actionable items. You can easily see, grab and reuse items, and be confident that they’re current and include all related comments and status. Forget about wordy “reading assignments.” You can share specific work components with your team for review and approval, without the risk of compromising security or access permissions that document shuffling causes. And when it’s time to pull it all together again to submit or archive a controlled document version, Jama can do that, too.

Skeptical? Make us prove it to you. Sign up for a free 30-day trial and give us a shot. No installation required.

And one proven way to handle them with speed and finesse.

For product managers and their counterparts, the road to launch is a fight to keep every task, every detail and every change grounded in business goals. It’s not enough to be fast. Or to deliver the right product. You need to do both. Yet, the tools product managers depend on are often the weakest link, and not up to the tasks of fast-paced iterative development. But whatever product management tools and methodologies you’re using, you’ll still need to tackle these 10 challenges:

Engaging all the right stakeholders in the most effective, efficient manner (knowing who to involve, when and how)
Tracking product, program and project details while responding to a constant stream of new information
Finding critical information you need at the moment you need it instead of searching through emails, spreadsheets, SharePoint, tribal knowledge in team members’ heads, etc.
Keeping teams in-sync and updated on what they are planning, building, testing and releasing
Prioritizing and re-prioritizing what goes into each release, based on new information, insights and pressures from multiple voices—everyone from front-end users to engineers to sales to support
Revisiting decisions and changes because you haven’t been able to capture context, discussions or approvals in an accessible manner
Identifying opportunities to reuse and synchronize projects, items and components to reduce risk and save time
Navigating and mastering the complexity of products, projects, processes, teams and communication
Struggling to delight business customers while juggling overtaxed resources and tight deadlines
Ensuring on-time, within-budget delivery of the right product

Check out The Product Delivery Problem (It’s Not You) to uncover the one surefire way to establish and maintain a strong connection between intended outcomes, development methodologies and customer value.

Do you have any particularly problematic product challenges not listed here? Share what’s on your mind in the comments or send us a tweet and read our next practical product management and development post here.