How PD works in Agile team

By Dingshan Li

PD (Product designer) is very important role in software development. They will provide detail requirements specification and business workflow, UI workflow. In traditional software development process, PD will prepare the detail requirement design document before develop team start to make software design. This kind of process will work pretty well if the requirements are clear and relatively stable. Also, there are enough PD resources to make the complex documents. But most of time, we cannot figure out the whole requirements clearly at the start stage. And the scope change is often happen. Another factor is that PD always need to work on more than one product and it is very difficult for them to spend much of time to work out a detail design document. So, what can we do to deal with this kind of issues?

Agile provides a methodology or framework for the team to develop software under the situation of changing scope. By focusing on high value requirement, separating the long lifecycle to be several short iterations and guarantee fully-test in each iteration, it can provide high-quality and expected software to the client. In this kind of framework, how PD works in the team? How they collaborate with others

Continue reading this article.

The Product Owner on One Page: Overview of the Product Owner Role

By Roman Pichler

The following diagram summarises the product owner's responsibility together with the role's key activities and artefacts.

Continue reading this article.

The Land that Scrum Forgot

By Robert C. Martin

Scrum is a starting point. In fact, it’s a great starting point. But, as a framework rather than a full-blown methodology, Scrum is deliberately incomplete. Some things—such as the best technical practices to use—are left for individual teams to determine. This allows a team to create the best fit between their project and environment and an assortment of technical practices.

While that selection of practices should belong to the team or organization rather than to a group of methodologists, the benefits of some practices are becoming so compellingly obvious that they warrant consideration by any Scrum team. But, too many Scrum teams become complacent after achieving some early productivity gains with Scrum. And they stop seeking ways to improve. Many fail to try the technical practices necessary for long-term success. In the following article, Robert Martin (perhaps better known as "Uncle Bob") tells us why so many Scrum teams fail to sustain the promise of their early successes.

Continue reading this article.

Heartbeats: The pace of a Scrum Team

By Rafael Nascimento

One of the challenges in the use of Scrum is to predict how much of functionality a team is able to deliver each sprint. Many try, in a vague attempt to create a metric, to assign a story point a certain amount of work to be delivered, rather than looking how a team play their roles and perform their deliveries. For example, a story point is equivalent to a CRUD with 8 fields that accesses a table in the database. This approach does not work, because a team is made up of people with different experiences, perceptions and problems (personal or professional). Individually and collectively, a team always has different emotional and technical characteristics  from other teams. Team members never take the same time that members of Team B took to adapt to each other. Teams will never manage exactly the same conflict situations or have the same productivity. Finally, in sets filled by human beings, there may even be a statistical  standard for productivity, but never an industry standard, accurate and predictable. There will always be a margin of error. Then comes a question for reflection: is it better to draft a plan and make your team follow this plan at any cost, in favor of a contract or corporate goal? Or would it be better to identify a target and track the performance and growth of your team, guiding it toward its mission, enjoying a harmonious, happy and highly productive environment, and make necessary adjustments to the project plan for the sake of your customers’ satisfaction, offering them transparency, with no surprises?

Continue reading this article.