Skip to main content

Agile Patterns



Avatar: Have a signal on an information radar that indicates who is working on what.

Backlog: Enumerate all work to be done in the form of an ordered list.

Controlled Failure: Terminate a project once it becomes clear that it is not viable. Accrued value is retained and project resources are freed for other activities

Done: Ensure all work is completed to a known standard, so misunderstanding is avoided and rework minimized.

Increment: Deliver a potentially releasable piece of work early and often.

Forecast: Predict completion time based on the estimated size of a backlog and a known velocity

Information Radiator: Make the status of a team and its work immediately apparent

Inspect & Adapt: Teams delivering value should be able to critique and improve their own working practices.

Kanban Switch: Have an appropriate agile way of working at each of three enterprise levels.

Iterate: Minimize stock-on-hand so as to deliver value more quickly and reduce waste.

Product Ownership: Provide a single business liaison who is able to represent customer needs in an accountable manner, able to provide effective pull on a team backlog, and who is empowered to make business decisions.

Relative Sizing: Allow a backlog to be ordered when it is difficult for team members to estimate the size of each item in a backlog.

Quality of Service: Vary the way backlog items are expedited and handled.

Swarm: Have all available resources work on one thing in order to expedite it as quickly as possible.

Test-Driven Development: First, prove that an unmet need has been met without breaking anything else. Then, optimize the solution.

Pivot: A structured course correction that allows a new hypothesis involving different choices to be tested.

Co-location: The placing of team members in physical proximity to each other so that the best communication and collaborative potential can be leveraged.

Refinement: The clarifying and ordering of items on a backlog so that they are ready to be worked on.

Scrum of Scrums: A collaborative activity between representatives of multiple agile teams in order to focus and replan around a shared purpose.

Championship: The accountability of a particular agile team member toward providing a needed skill or capability.

Scrumban: The gradual replacement of Scrum Sprints with a more Kanban-like system of continuous flow.

Single-piece flow: A special case of limited WIP intended to maximize throughput, such that a team only has one item of work in progress at any given time.

Time-boxing: The discipline of ensuring that an event, such as an inspect-adapt meeting or an iteration, does not exceed a maximum period of time.

Trade: The moving of one or more work items out-of-scope so they can be replaced by more valuable work of similar size.

Management by exception: The delegation of authority to act within specified tolerances, only involving others if those tolerances are exceeded.

Peer: A team member who can support team responsibilities and accountabilities.

Teamwork: Getting people to collaborate on work being actioned so that increments are developed as efficiently as possible.

Release orchestration: Ensuring that delivery teams contributing to the release of a product or service are aligned to do so, and that no opportunity to address market demand is lost.

Epic: The grouping of certain items on a backlog in terms of a highvalue feature.

Metrics: Provide actionable, non-subjective data so that informed decisions can be made.

Minimum viable product: Deliver a small portion of value in order to provide an early return on investment, and/or to allow lessons to be learned as quickly as possible.

Proxy product ownership: Authorizing a suitable stand-in should a product owner be indisposed.

Value stream: Understanding the value being added at each stage of a process with a view to eliminating waste.

Sponsorship: The sense of urgency conveyed by management in support of an initiative, and which must be sufficient to overcome organizational gravity.

DEALING WITH ANTIPATTERNS Agile antipatterns are organizational impediments to agile practice that should be challenged and removed. They are best tackled by means of the patterns that are most likely to eliminate them.

Cherry-picking: Team members are often tempted to select items from a backlog that they expect to be the most gratifying for them or the easiest to do. Swarming on items may help, as it requires team members to collaborate more closely.

Cloned avatar: If development team members are given unclear priorities in a high-pressure environment, they can be tempted to start development on an item without first completing the work they have in progress. By duplicating their avatar, they can then claim to those exerting the pressure that work is underway. Limiting work in progress is likely to be beneficial, as a pull-based system ought to be encouraged.

Death march: It can be politically difficult to cancel a struggling initiative if it has already absorbed significant resources. To do so may imply that the project has been a poor investment and that the time and money committed has been lost. Stakeholders would prefer to continue with a failing project and hope for sudden and improbable change. Controlled failure must be recognized as an option.

Disguised project: Some changes to IT systems can be trivial in nature, such as minor amendments to site content or defect fixes. This type of work is considered to be "business as usual" (BAU) and as such, it is often absorbed by the organization-at-large as an operational expense. Departmental stakeholders who want more substantial changes must usually resource a suitable project from their capital budgets. They therefore have an incentive to disguise such work, either by misrepresenting it as a normal operational small change or by breaking it up into a series of small changes that they hope will slip through a BAU work-stream unnoticed. The Kanban sandwich and value stream patterns might provide remedy

Unbounded timebox: Allow an indeterminate amount of time for the completion of a task. Teams can be tempted to try to extend an available time-box if doing so increases the chances of an intermediate goal being met. The team can then create the illusion of success even though the deliveries that were forecast have not been made. Good time-boxing will avoid this by ensuring that a maximum time limit is observed.

Uncommitment: Team members who do not value the product or Sprint goal, or who are allowed to accept other priorities, may be tempted to admit unplanned work into a Sprint. This can include work from forceful parties which the product owner does not value. Strong product ownership is important if this problem is to be overcome.

Undefined done: Progress work as quickly as possible and without sufficient regard for quality. Technical debt is likely to result. Observing a definition of done that assures each increment as being of release quality is essential.

Unlimited WIP: When faced with competing and vociferous stakeholder demands, team members can feel obliged to action multiple items simultaneously. In an attempt to pacify stakeholders, they can therefore claim that an item is being worked on and is no longer enqueued. Both good product ownership and a team determination to limit WIP appropriately are needed to overcome this.

Distributed team: Physical constraints, such as desk space and the wider geography of an organization, may inhibit the co-location of team members. The need for agile team members to work in proximity to each other can present logistical issues that managers are unwilling to overcome. As such, a logical team boundary will be made to span physical boundaries. Managers can thus avoid an immediate resourcing issue while offloading the management of any risk incurred to the teams themselves. Co-location is generally advantageous and can reinforce the teamwork pattern.

Management by reporting: Highlight issues and concerns while deferring the risk of taking action to others — at least to a later date. The hope is to avoid personal exposure should there be negative consequences from taking action. Management by exception can be a more practical alternative in so far as it establishes clear tolerances.

Micromanagement: Managers can find it hard to delegate operational responsibilities. There are a number of possible motives for a manager wishing to retain control. For example, the manager may not trust others to perform the duties satisfactorily, or he or she may simply enjoy dealing with operational matters. A servant leader will coach more constructive behaviors, and the team should be encouraged to inspect and adapt its own way of working. Again, establishing clear tolerances through management by exception can help.

Sprint zero: Set up an agile project, while contextualizing unplanned initialization overheads in agile terms. No value is released, and empirical process control is not established. Ensuring that the iteration and increment patterns are used together can be wise.

Time theft: Agile teams draw their work from prioritized backlogs, which means that those waiting at the bottom of the queue may expect some degree of delay. Such parties may thus be incentivized to circumvent the backlog management process by approaching team members directly for assistance. Parties seeking assistance in matters that lie beyond the team's remit can have an additional incentive, given that such activities would not be appropriate for inclusion on the team's backlog in the first place. A good servant leader, such as a Scrum master, will protect a team from such interference.

Too busy: Key stakeholders often have responsibilities that span multiple teams (e.g. product owners, senior designers, and architects). If they do not value a team's product or service particularly highly, they may be tempted to abdicate or defer their stakeholder duties in order to give other matters their attention. Sponsorship for the initiative is essential. Controlled failure may be the best option in severe cases.

Unbounded team: The allocation of team members to certain workstreams implies that they will not be available for others. This is a constraint on organizational behavior since it means that managers cannot assign people to multiple duties in a reactive or ad hoc manner. Organizations can be tempted to compromise on such discipline for the sake of expediency or in support of "firefighting." Teams should be able to inspect and adapt their own membership and to frame their own teamwork commitments.

Unresolved proxy: Multiple stakeholders can have an interest in a product and each may only be able to articulate the requirements in their area. Consequently, a senior product owner may be tempted to delegate ownership to multiple proxies. Good product ownership ensures that one clear authority is accountable for value.

Vanity metrics: Use only the most favorable metrics in order to strike a posture. Team members can be tempted to show their efforts in the best light rather than in a more objective one. Good metrics are based on data which supports inspection and adaptation and the taking of informed, constructive action.

Waterscrumfall: Organizations may often have the goal of adopting an agile way of working, but they can lack the cultural grit to transition away from an established stage-gated culture. They then attempt to affect a compromise in which an iterative development approach is encapsulated within a development stage. In doing so, they hope to leverage the benefits of agile practice while not actually changing the organization's delivery approach or the terms of reference that are comfortable to stakeholders. The transformation pattern helps challenge this thinking, as it puts empirical process control at the heart of an enterprise change attempt

Comments

Popular posts from this blog

Access multiple Databases in JPA

According to JPA specification we can define multiple "persistence-unit" elements (i.e. like below) in persistence.xml file and can easily refer them inside Dao layers as this. public class PolarDaoImpl {     @PersistenceContext(unitName="PolarPU")     protected EntityManager entityManager; -- } public class BearDaoImpl {     @PersistenceContext(unitName="BearPU")     protected EntityManager entityManager; -- } Checkout sample persistence.xml <?xml version="1.0" encoding="UTF-8"?> <persistence version="2.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">     <!-- Database 1 -->     <persistence-unit name="PolarPU" transaction-type="RESOURCE_LOCAL">         <

JPA 2 new feature @ElementCollection explained

@ElementCollection is new annotation introduced in JPA 2.0, This will help us get rid of One-Many and Many-One shitty syntax. Example 1: Stores list of Strings in an Entity @Entity public class Users implements Serializable {     private static final long serialVersionUID = 1L;     @Id     @GeneratedValue(strategy = GenerationType.AUTO)     private Long id;     @ElementCollection     private List<String> certifications = new ArrayList <String> ();     public Long getId() {         return id;     }     public void setId(Long id) {         this.id = id;     }     public List <String> getCertifications() {         return certifications;     }     public void setCertifications(List <String> certifications) {         this.certifications = certifications;     } .. }         Users u = new Users();         u.getCertifications().add("Sun Certified Java Programmer");         em.persist(u); Generated Tables    Users    Co

Reuse JPA Entities as DTO

Note : Major design advantages of JPA Entities are they can detached and used across tiers and networks and later can by merged. Checkout this new way of querying entities in JPA 2.0 String ql = " SELECT new prepclass2.Employee (e.firstname, e.lastname) FROM Employee e "; List<Employee> dtos = em.createQuery(ql).getResultList(); The above query loads all Employee entities but with subset of data i.e. firstname, lastname. Employee entity looks like this. @Entity @Table(name="emp") public class Employee implements Serializable {     private static final long serialVersionUID = 1L;     @Id     @GeneratedValue(strategy = GenerationType.AUTO)     private Long id;     @Column     private String firstname;     @Column     private String lastname;     @Column     private String username;     @Column     private String street;     @Column     private String city;     @Column     private String state;     @Column     private String zipc