#onenote# Agile

Agile pocket guide

http://techbus.safaribooksonline.com/book/software-engineering-and-development/agile-development/9781118461808

 

Servant Leadership

Your job is to:

 

  • Remove obstacles or resolve dependencies between team members and teams.
  • Remind the team of mission/value statements for each project.
  • Ensure that the team adheres to the defined rules of Scrum or processes accepted by the team.
  • Protect the team and filter nonessential information and meetings.
  • Give updates and information regarding enterprise releases or project updates.
  • Set the example for the team and for the business.

 

Leader Questions

Every chapter in this book ends with a set of three questions you will want to ask your team.

  1. Who do we need to meet with or connect with to help with that task?
  2. Is there anything we’ve missed or not considered?
  3. What do you need from me, and what can I do to help?

 

High-performance teams are a community. A community environment:

 

  • Breeds group interdependence, which in turn increases the success of individuals as opposed to relying on authoritarian control (top-down management or command-and-control management).
  • Enables the team to set goals and solve problems together.
  • Continually monitors and assesses work progress.
  • Celebrates achievements and rewards individuals.
  • Decreases managing overhead by the Leader, thereby enabling the Leader to focus on road-mapping work and giving specialized help as needed.
  • Encourages training members as a group, which promotes a higher work ethic and increased productivity.
  • Produces measurably great results over time.
  • Differentiates roles that people are uniquely fit to fill (see Chapter 17 for more information).
  • Coaches the team to give candid feedback and support to other team members.
  • Keeps the best talent, moving or removing unproductive members of the team.

A high-performance team is one that embraces the Toyota way of kaizen, which means “continuous improvement.” Your Agile Team will be one that has members who continually communicate with one another, continually improve themselves, the team, the processes, and the business. Most of all, your team, through its success and transparency, will honor its commitment to the business stakeholders and grow trust between Tribes. Your Agile Team may be ready to move in this direction; if this is the case, task the members to consider their readiness and willingness.

 

Leader Questions

 

  1. Do we have the processes and tools in place to build this type of community?
  2. Are we physically located in an area that promotes communication and collaboration?
  3. Are we meeting regularly enough to go over existing problems, improve existing processes, and be aware of current and future needs?

 

Team and Business Cultural Dynamics—Team Science™

I’ve used several assessments in the past that have fallen flat on their faces. The most effective team- and cultural-assessment tool built specifically for use within the team context is Team Science™ (www.myai.org). This tool has allowed me to be far more successful as a coach and consultant to my clients in that it quickly allows me to assess the cultural dynamics, deficiencies, and opportunities in each team I work with.

 

Team Science™ (Figure 17.1) helps businesses and teams by:

 

  • Optimizing each employee and revealing or her potential and strengths.
  • Enabling managers and executives to build the right teams for the right projects.
  • Allowing hiring managers to recruit and employ the right candidates based on cultural and strategic fit.
  • Increasing awareness of team dynamics and collaboration styles.
  • Helping with decision making and conflict resolution.
  • Focusing on how to choose the right Leaders.
  • Encouraging you to empower your employees.

 

 

Chapter 25

Personal Kaizen—More on Servant Leadership

The following is what I consider to be the Top 10 Personal Skills for a Servant Leader. I suggest you read each one and let it resonate within you.

 

  1. Communicative and social—A Servant Leader must be able to communicate well with all people, teams, and business levels. Understanding your communication style is imperative to knowing how to engage effectively with people from all walks of life and backgrounds!
  2. Facilitative—A Servant Leader must be able to lead, manage, and even coach teams of people to work collaboratively, cohesively, and effectively. A great facilitator knows how to grease the wheels of productivity in a stagnant group. You also know how to make meetings less boring and more energizing by utilizing an array of facilitation techniques to keep everyone moving forward.
  3. Assertive—A Servant Leader must be able to ensure the right things on which to focus and the right concepts and principles to follow. You must be a voice of reason and authority when needed. You must be able to make the tough calls and be a respected supporter and voice of those who may not have the gumption to speak up.
  4. Situationally aware—A Servant Leader must be the first to notice issues as they arise and be tactful enough to address them when needed. You must know when to take a coaching role, or when to delegate issues to upper management. A Servant Leader who monitors the pulse of a situation can often preempt conflicts or issues before they reach a boiling point.
  5. Enthusiastic—A Servant Leader must be high energy, with focus. While many great leaders have approached their role through their ethos of passivity, they share common ground with their limitless energy toward the goals they have set for themselves and their people. People want to follow an enthusiastic leader. People will rally around your enthusiasm.
  6. Continually improving—A Servant Leader must be one who lives a life of continuous improvement, and helps drive continuous improvement in his or her team, business, and personal life. You didn’t stop learning after you got your high school or college degree, did you? Tons of learning opportunities occur every day in the office. Make them count.
  7. Conflict resolution—A Servant Leader must be able to handle conflict well and be able to facilitate discussion, alternatives, or different approaches when conflict arises. A clear head, with your emotions in check, is an obvious prerequisite for this. Conflict resolution isn’t easy. Certainly, being situationally aware and preempting conflict would be a plus here.
  8. Attitude of empowerment—A Servant Leader is one who coaches individuals and teams toward self-organization. This means that you must allow individuals to have the right balance of autonomy, self-transcendence, and management oversight. You aren’t in the manufacturing days anymore. People aren’t just cogs in a big wheel. They need to feel like they can self-manage at certain levels and have the ability to figure out how they will do the work, and work within the frameworks of managers who set the goals of what needs to get done. You should be the enabler who removes any impediments to individual and team success.
  9. Attitude of transparency—A Servant Leader must desire to foster to a healthy dose of disclosure and transparency about practices and processes in the business. Transparency also grows trust between your team and the rest of the organization. This isn’t a call to build a lot of status reports. Rather, it is call to monitor the amount of value-added information that needs to be open and available for the business to base decisions on. A great way to begin is to have candid conversations with management to know exactly what they need to know, focus on that, and then iterate and improve as you go.
  10. Coach mentality—Remember a great coach of your little league team? Or a great mentor during your younger school days? Those people not only led by example, but they also added pressure as necessary to help you improve. Coaches put emotional capital into the game. They go above and beyond the call of duty. What is it that you need to do to encourage, mentor, and lead your team?

All of these suggestions are simply just that. In reality, this list is a big challenge for many. To begin, take each idea presented here and focus on it for a week. Write down the pragmatic steps that you need to take to start being a better Servant Leader. Begin slowly, and then inspect, adapt, and improve over time.

 

 

Here is a list of things to start doing to improve your team and company:

 

  • Start small and continue to execute—Take the basic fundamentals of iterative development and practice it with your team. As improvement and change begin to take hold, try something new. Always remember to assess changes in retrospect. Are they working well? If so, continue on. If not, find out why, or discontinue!
  • Review and understand other processes and methodologies, and employ as needed—There are always opportunities to leverage other techniques to provide value to the current way in which you are doing things. Google “Learn more Agile software development methods” and see what’s out there for you to use.
  • Experience the outside world—Go to conferences, meet-ups, and local gatherings of professionals. To grow your professional skills and keep increasing your value to your team and company, you have to learn and relearn technologies and methodologies. Put in a little time and money and you could find yourself across the table from someone far more influential and smarter than you are. Take those opportunities to network and grow!
  • Read, read, read—Read blogs to stay up to date with industry leaders. What are they saying? Read books by powerful authors in various industries. Don’t like paperbacks? Download them to your electronic reader!
  • Start a company interest group—You’d be surprised at how many people are interested in making work a better place. Find your niche. Start a book club. Kick-start the company by grabbing influential people to help make your company or team just a little bit better.
  • Start writing, blogging, and tweeting—Start writing down your personal experiences in your profession. There is a lot you can learn through expounding on your experiences. You’ll also meet like-minded people who are on the same journey as you are. Follow experienced professionals on Twitter. See what they are reading. Leverage their vast knowledge to change your reality at work and at home.

 

Scrum master – How to develop a team

 

 

Improvement Communities

An improvement community (IC) is a group of individuals who join together to work collaboratively to improve the organization’s use of Scrum. An IC may form when individuals notice an item on the ETC’s improvement backlog and decide to work together to achieve that goal. Or an IC may form because individuals see and are passionate about an improvement opportunity that hasn’t made the ETC’s radar yet. IBM, for example, has five ICs, which are focused on test automation, continuous integration, test-driven development, the role of the product owner, and the general use of Scrum itself.

 

Deliver agile projects using scrum

Training on 11-12 Jun 2015 by Erik Yek, ESI International

 

Know agile -> doing agile (scrumbut)-> be agile

 

Agile approach

  • Scrum
  • Kanban (Lean)
  • XP

 

Agile principle

  • Open
  • Transparent
  • Adaption

 

 

Sprint (Iteration)  counts on the productivity hour, no more than 4 weeks

Constantly engage with users(business)

Three roles

  • Product  owner  (certification:  CSP)
    •  Must to have BA skill and domain knowledge
    •  KEE – Knowledge(Know  your R&R), Empower(can make decision),  Engaged
    • Don’t let your team disturbed by other ppl
    • Prioritize the product backlog item in product backlog refinement   (prioritize by business value, technical risk, technical dependence, POC<– to decide the certainty of a task/story success)
    • Product backlog refinement  = Product backlog grooming

 

  • Scrum master  (certification:  CSM)
  • Delivery team (DBT – Develop, Build, Test)  (certification:  CSD)

Sprint  artifact

  • PSP – Potentially Shippable Product  (or MVP – minimal Viable product)
  • Burn-down chart

 

Team velocity is measured by story point

 

Sprint0 : 4-6 weeks, no longer than 8 weeks

 

Sprint Planning

  • Sprint planning takes max 4 hours ( 1 week sprint, 1 hour)
  • Store point  is estimated by  relatively estimation(Planning poker), not by absolution estimation.
  • Task – absolute hour,  also judge by the team (similar to planning poker)
  • Team mate pick the task by themselves, not assigned by PM
  • Put a buffer in the sprint (e.g. plan 6 hours a date)

Scrum Master

  • Problem sovler
  • Process enforcer
  • Facilitator
  • Protector (protect the team from distribution from  product owner..)
  • Has the power to terminate the sprint (in emergency, absolute necessary)

Delivery team

  • Min 3 ppl, max 9 ppl (best practice)

Sprint Review

  • Max 4 hours (1 week sprint, 1 hour)

Sprint retrospective (45 mins for 1 week sprint)

  • Improvement log

No connection between  story point and actual hours

Velocity is basing on store point, Velocity != productivity ,  can’t compare velocity between projects

A story should be completed in a sprint

Theme > Epic > Story, Epic can contain 2+ stories

 

User story should be owned by PO, non-user story should be owned by the delivery team

SCROOL <– IOS Tool , Poker planning tool

 

Estimation

  • 1st to select the baseline story
  • All other store should be estimate by the baseline story

Estimation factors

  • Complexity
  • Doubt (Risk)
  • Effort

 

Pig

  • PO
  • Scrum Master
  •  Delivery Team

Chicken

  • Other stakeholder/interest party

 

Sprint Retrospective

Approach 1

  • Continue
  • Start
  • Stop

Approach 2

– What went well

– What went badly

– What should be improve

– Any other great ideas

– First set the stage to make it safe!

Improvement log

 

Scrum team

Team Size

  • Two-pizza scrum team
  • 7 ± 2

 some of the factors of a team to consider are the following

  • Include all needed disciplines
  • Balance tehnical skill levels
  • Balance domain knowledge
  • Seek diversity
  • Consider persistence

Good user story

I (= Independent) N (= Negotiable) V (= Valuable) E (= Estimable) S (= Small) T (= Testable)

SMART Task

S – Specific

M – Measurable

A – Achievable

R – Relevant

T – Time-boxed

Rougly estimate by T-shirt size in building the backlog story but need to shift to story point when doing sprint planning

Acceptance criteria

– Functional Criteria

– Non-Functional Criteria

– Performance Criteria

Production Support and Scrum

– Have two backlogs—one for development features and one for production support issues. The Product Owner sets a guideline ratio for planning whereby the team will take, for example, 70 percent from the development backlog and 30 percent from the support backlog

– Bugs as Feature Requests

– Emergencies – play the “emergency card”

Agile Values

 

Adaptability

  • Responding to change

 

Transparency

Scrum keeps everything about a project visible to everyone

Scrum enforces transparency inside and outside the team. Transparency is vital to the Scrum process, as it allows everyone to see and understand what is really happening in each sprint, achieving a bigger and better communication and trust on the team and in this methodology

 

Simplicity

the art of maximizing the amount of work not done–is essential.

<–

This translates to:

Always do the simplest thing that does the job required.

This just means cutting out needless effort wherever possible, including within your own agile process.

The KISS principle is related – keep the program simple, it will be easier to write, easier to maintain, and out the door faster.

 

Unity

  • Feedback  & Customer collaboration

 

 

 

Agile Development Teams Must Be Empowered

 

The project team must be empowered to make decisions in order to ensure that it is their responsibility to deliver the product and that they have complete ownership. Any interference with the project team is disruptive and reduces their motivation to deliver. The team must establish and clarify the requirements together, prioritise them together, agree to the tasks required to deliver them together, and estimate the effort involved together

 

Agile Maturity measurement

From http://info.thoughtworks.com/rs/thoughtworks2/images/agile_maturity_model.pdf

The Maturity Model

In order to achieve our ideal, it is essential to cover all parts of the process of building, deploying, testing, and releasing software.

Build management and continuous integration are concerned with creating and maintaining an automated process that builds your application and runs tests on every change and then provides feedback to the whole team on the process.

Environments consist of the entire stack your application requires to work:

hardware, infrastructure, networking, application stacks, external services, and their configuration.

Release management is defined by Forrester as “the definition, support, and enforcement of processes for preparing software for deployment to production.” We have added considerations around compliance to this area, since conformance to regulatory environments is often one of the strongest constraints on release management.

Testing, whether through automated tests or manual processes such as exploratory testing and user

acceptance testing is designed to ensure that software contains as few defects as possible as well as

conforms to non-functional requirements. We have focused on the areas of testing that are most relevant to building and releasing software.

Finally, data management (usually, but not always, in the context of relational databases) forms an essential part of the deployment and release process, since it is a frequent source of problems when releasing or upgrading software.

To ensure each part of the process is given due attention, we have divided the model into five sections.

Machine generated alternative text:
Practice
Level 3- Optimizing:
Focus on process
improvement
Build management and
continuous IntegratIon
Teams regularly meet lo
discuss integration
resolve
them with automation,
faste feedback, and
better_visibility.
Environments and f Release management
deployment and compliance
Testing
Data management
All environments
managed effectively,
Provisioning fully
automated Virlualizabon
used  applicable
Operations and delivery
teams regularly
collaborate to manage
risks and reduce cycle
time
Production rollbacks rare.
Defects fOUnd and I)
immediately
Release to release
fb 
database performance
and deployment process.
Level 2- Quantitatively
managed:
Process measiied and
controlled
Build metrics gathered.
made visible, and acted
on. Buikis are not left
broken
Orchestrated
deployments managed.
Release and rolbadc
processes tested
Environment and
application health
monitored and proactively
managed. Cycle time
monitored.
ouaiity metrics and
trends tracked Non
functional requirements
defined and measured
Database upgrades and
roilacks tested with
every deployment.
Database performance
monitored end optimized.
Level 1 - Consistent:
Automated processes
applied across wtiole
application lifecycle
Automated build and lest
cycle every time a change
is ooivwn.tled
Dependenoes managed.
Re-use of scripts and
tools,
Ftily automated, self-
service push-button
process for deploying
software. Same process
to deploy lo every
environment
Change management and
approvals processes
detined and enforced,
Regulalory and
conliance conditions
met
Automated unit and
acceptance tesis, 
latter written with testers
Testing 
developrrwnt process.
Database changes
performed automatically
as pail of deployment
process
Level 0? Repeatable:
Process documented and
partly automated
Level-I - Regressive:
processes La-irepeatable.
Regular automated bjld
and testing Any build can
be re-created from source
control using automated
process.
Manual processes for
building software. No
Automate抣 c1€.ploym.nt :o
some environments
Creation of new
environments is cheap.
All configuration
crernafized F versioned
Manual process for
deploying software.
Envlronme,*specllic
bew. Envwonments
provisioneci manuasy
Painful and infrequent,
but reliable, releases,
Umiled traceatality from
requirements to release.
Infrequent and twrelieble
Automated tests written
as part of story
development.
Manual testing after
Changes to databases
done with automated
scripts versioned with
application.
Data migrations
vio anci
performed manually
poorly controlled, and
reactIve
management of artifacts
and reports.
releases
development,

From https://community.apigee.com/articles/2935/agile-assurance-advice-for-starting-the-agile-jour.html

Machine generated alternative text:
? L, fl ? I
Iterations
- Tr.ckirig of
? Velocity.
I down
F tilt, me
(orScn Mast
r.n mnb?
.9ile
E t1 ec ?
tooli
roel
It erat iorv .l.as
M襫騡an .r4
- Rigor in reSO1v4
quenes 
- Code lronng
ggcnrq Lke.Iv
_Jea I.eni.t.I.n.
don. (DoD)
. Task Boards.
Sticky Notes.
Video C04if
Confidence in
E st e m atiorl
. T昪Fri.cel
Manogeme*
- AaAom.t Unit
?-棗?-
.0?
ete
- Test At.ornac,or
D.fct Analysis
- Ex pl oratory
Testing
? Aa*ornet.d I
D.pl oymer*
. R.I.as.
Manaemefl
? riont.zed  .
PrOdLCJ .€fklog
. Che
4* at
.? elI levels
- Governance
Meat ing s
. <nowledge
M gem erd
. Focijs on long
tel-rn P40JCt
i-Oa&n 
- Antional
Metrics 棗憲
to 8iId
Menog. .-.. -
Cod. 
Tat, rv
Application of
M.lncs in
AI)elyS.S and
Prect ion
- Periodic
Governance
M e.e(i ng s
. Cord irsjo..js
aiIob.Iity of
,nfra-strI,cIL%e
- Dcision on
using T DO and
04 her 8dv anc.d
tectwquea
- Moro then 6096
0i404neliorl of
tests
Defect
Prov erd ion
- Frequerd Bealds
(once or several
times a day)

From http://blogs.mindtree.com/distributed-agile-maturity-curve-part-1

Sprint Planning

Capacity (time) & velocity (points) based planning

 

From <https://www.scrum.org/Forums/aft/1552>

 

For a new Scrum team with no history of velocity, one common way to forecast a team’s velocity is to have the team pull PBIs one by one to determine what PBIs the Team could deliver during a single sprint.

 

There are 2 way to perform capacity based planning:

  1. Estimate how much time it will take to have a PBI be Done.
  2. Decompose each PBI to actionable tasks. Estimate how much time it will take to execute the tasks.

 

The Team could simply add the hour each PBI/task cost and compare to Team’s capacity to determine what PBIs it could commit.

 

If the forecasting or commitment seems reasonable, the Team could simply add the size of the PBIs pulled to Sprint Backlog and use that as the Team’s forecasted velocity.

 

There are no switch problem, but using Velocity from now on.

 

There is a disadvantage by using capacity based planning or idea hour as estimating unit of PBIs.

Image that a PBI’s size is 24 hours in Product Backlog.

The team pull it to Sprint backlog and decompose to 5 Tasks listed as follows:

Task1: 6 hrs.

Task2: 4 hrs.

Task3: 8 hrs.

Task4: 5 hrs.

Task5: 4Hrs

 

Total: 27 hrs.

 

There should be a confusing between a PBI and tasks decomposed.

 

Estimates are not commitments.

 

For planning purpose, velocity during the “what” part is most useful when expressed as a range. During the “how” part, if the cost is out of range, they may re-negotiate with the PO to remove several item or just start the sprint. Velocity is measured by adding the size of the PBIs that are “COMPLETED” by the end of the sprint. Velocity does not include the size numbers of partially completed PBIs.

 

As the Team builds up a history of actual velocities, an effective velocity range will be used as a planning tool and as a team diagnostic metric.

 

From <https://www.scrum.org/Forums/aft/1552>

Story point vs Ideal hour

For any story and its sub tasks…what is the right thing to do from Agile Scrum perspective…choose from option 1 or 2 or 3 below:

Option 1:

  • Estimate the story size in story points using poker planning
  • Breakdown the story into a list of smaller tasks
  • Let the development team Estimate in hours, how long will each task take?
  • Start development

Option 2:

  • Estimate the story size in story points using poker planning
  • Breakdown the story into a list of smaller tasks
  • Let the development team distribute the storypoints (Parent story point size), to each sub task
  • Start development

Option 3:

  • Estimate the story size in story points using poker planning
  • Breakdown the story into a list of smaller tasks
  • Start development

 

From <http://stackoverflow.com/questions/17704998/agile-scrum-storypoints-for-story-and-hours-for-tasks-on-the-story>

 

 

The basic principle is understanding what these tools are for, it all becomes obvious afterwards.

Story Points

Story points estimate… stories, but also sprint capacity. In practice, points are a tool to forecast which stories the team will be able to deliver in a specific sprint. They are popularly chosen from a set of pseudo-Fibonacci numbers, or powers of two, but I’ve also seen t-shirt sizes and also people advocating a 1-point-for-all strategy. The size of stories is estimated by the whole team and so is the sprint capacity.

The key point is: points are only used to estimate how much stuff can be done in the next sprint. The time size of the sprint is fixed, the capacity is estimated in points and the size of the stories is estimated in points.

Ideal hours

Stories are broken in single(*) developer ideal hours to generate a sprint burndown. They can be estimated by single developers. Their purpose is to monitor how much work is left to do in the current iteration. Tasks are estimated in terms of hours left and the estimate is constantly retouched during the sprint. For example you can start a task estimating 6 hours, then after a day have still 6 hours left (or 8, or 4, or 0!). Estimates change as tasks are built, so there’s probably less to do, but a partial measurement of how long it took. So for example a task might be estimated at 4 hours. If the task is 50% after 3 hours, the estimate is changed to 3 hours left.

The key point is: ideal hours are to estimate the amount of effort left to do in the sprint. They are not used at planning time and they are a dynamic quantity representing the current state of play.

(*) Or pairs if you pair-develop

TL;DR

You only need story points at the planning meeting, however tasking is the first activity of the sprint as the team reports the first estimated total of hours left.

 

From <http://stackoverflow.com/questions/17704998/agile-scrum-storypoints-for-story-and-hours-for-tasks-on-the-story>

Backlog grooming

 

Purpose: A Backlog Grooming session can be used to:

  • Write user stories (it is possible to build a Product Backlog “from scratch” in a series of one or more StoryTime sessions)
  • Break down user stories that are too big (epics)
  • Improve user stories that are poorly written
  • Estimate backlog items
  • Add acceptance criteria
  • Look deeper into the backlog to do longer-range technical planning – See more at:

From <https://www.scrumalliance.org/community/articles/2011/march/how-to-hold-an-effective-backlog-grooming-session>

 

#NoEstimation

 https://www.youtube.com/watch?v=v470U66hHPc

https://www.youtube.com/watch?v=QVBlnCTu9Ms

 

Estimation – problem

– big gaps

– different result person by person

– absolution estimation  vs relative estimation

– relative estimation still desnt know the duration to compelte a job

– 2 sp does’t mean two times of effort than 1 sp

– even using sp, managment still expect a timeline

– absolution estimation, sp, velocity focus on too much on output, not outcome

– static velocity means some one is gaming it

– scope vs time vs cost

 

https://www.youtube.com/watch?v=5oMk2oRJNbc

 

estimation movement

velocity is killing agility

 

 

NoEstimation means

 

 

 

 

 

 

 

I have watched some #NoEstimates webinar,

https://www.youtube.com/watch?v=v470U66hHPc

https://www.youtube.com/watch?v=QVBlnCTu9Ms

https://www.youtube.com/watch?v=G-zy4i6F0lI

Personally i am convinced by their points but still having some queris:

  1. How do reply managers’ question: “When the project can be completed?” with #NoEstimates
  2. Breakdown every story equally to 1 story point isn’t an estimation?

 

What’s your view? guys

 

https://www.youtube.com/watch?v=dnbPjPxRglE

 

 

 

 

https://www.youtube.com/watch?v=7ekx3QXnTCA

 

 

 

TYPES OF TECHNICAL USER STORIES

Sometimes it’s useful to identify different types of technical stories. Mostly because it gets your team thinking at different levels about all of the needs they might have to properly implement within the application.

  1. Product Infrastructure – stories that directly support requested functional stories. This could include new and/or modified infrastructure. It might also identify refactoring opportunities, but driven from the functional need.
  2. Team Infrastructure – stories that support the team and their ability to deliver software. Often these surround tooling, testing, metrics, design, and planning. It could imply the team “creating” something or “buying and installing” something.
  3. Refactoring – these are stories that identify areas that are refactoring candidates. Not only code needs refactoring, but also it can often include designs, automation, tooling, and any process documentation.
  4. Bug Fixing – either clusters or packages of bugs that increase repair time or reduce aggregate of testing time. So this is more of an efficiency play.
  5. Spikes – research stories that will result in learning, architecture & design, prototypes, and ultimately a set of stories and execution strategy that will meet the functional goal of the spike. Spikes need to err on the side of prototype code over documentation as well, although I don’t think you have to “demo” every spike.

From <http://rgalen.com/agile-training-news/2013/11/10/technical-user-stories-what-when-and-how>

Modern agile

  • 用“使员工更加优秀”原则替换“客户合作高于合同谈判”;
  • 用“持续交付价值”原则替换“工作的软件高于详尽的文档”;
  • 用“快速地试验并学习”原则替换“响应变化高于遵循计划”;
  • 用“以安全为先决条件”原则替换“个体和互动高于流程和工具

From <http://www.infoq.com/cn/news/2016/08/agile2016-modern-agile>

 

Pod

Summary:

Agile pods are small custom agile teams, ranging from four to eight members, responsible for a single task, requirement, or part of the backlog. This organizational system is a step toward realizing the maximum potential of agile teams by involving members of different expertise and specialization, giving complete ownership and freedom, and expecting the best quality output.

Pod Organization

An agile pod is designed as per the requirement of the deliverable, involving varying levels of management, development expertise, QA, and creative talent. These teams are customizable and may change depending on the current requirements, creating a relevant ecosystem leading to maximum innovation and faster delivery times.

Pod Features

Agile pod teams are designed to be self-sufficient. The team is self-organizing and works with minimum supervision, creating a higher sense of ownership and maturity. Also, because most required expertise is available at hand within the team, there is a minimum level of dependency on people outside the pod. The pods stay together until the requirements keep coming for their teamsay, for one release cycle.

A pod consists of the following team members:

1. Core team: These team members are dedicated full-time to working for their pod. They are part of all discussions, decisions, and standup meetings. The competencies of the core team members add up to the competency of that pod. The core team members may be shuffled between pods during or after the release cycle according to the expertise required.

2. Part-time specialists: These team members are available as part-time resources to support specialized project needs of different pods. They may be working for multiple pods at the same time. Examples would be a UI designer, a white box tester, or an automation engineer.

3. Pod leader: The pod is led by a pod leader, who is responsible for prioritizing the work with the business management team, clarifying requirements, and replenishing the queue for upcoming projects periodically.

Dos:

      • When you decide to adopt agile pods, prepare the team members by training them in that direction before the actual transition.
      • During the onboarding time for the pods, spend time with each team member to clear doubts about the process.
      • When putting teams together, take care that their skill sets complement each other. Think about people issues among team members of a pod. You do not want friction or resistance among members of the same team. Try to resolve any differences before the team moves to a pod. If there is friction, the project managers should facilitate a resolution. In my experience, when working in an agile pod, a lot of things do get sorted out on their own, too!
      • Get the team together. Even if they are placed globally, get them to meet and sit together periodically to improve communication levels.
      • Have an ongoing process to discuss what the team is learning and which situations were tackled better and faster because of being in a pod.
      • Share the best practices being followed within one pod with other pod leaders, and encourage an open learning environment.
      • Leverage the use of tools as much as possible, paying attention to the team’s suggestions.

Don’ts:

      • Self-managing is an idea that needs to be ingrained in the team over time. Do not expect it to begin overnight. Some handholding time will be required for the team, especially for the pod leaders.
      • Don’t introduce new technology or tools midway through the process. Let the teams decide on the tools and processes they need, and get the best results out of them.
      • Don’t micro manage on hours, days

From <https://www.agileconnection.com/article/using-agile-pods-realize-potential-your-team?page=0%2C2>

Machine generated alternative text:
1b AI ourny
W,te,aH

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s