ThoughtWorks
  • 联系我们
  • Español
  • Português
  • Deutsch
  • English
概况
  • 工匠精神和科技思维

    采用现代的软件开发方法,更快地交付价值

    智能驱动的决策机制

    利用数据资产解锁新价值来源

  • 低摩擦的运营模式

    提升组织的变革响应力

    企业级平台战略

    创建与经营战略发展同步的灵活的技术平台

  • 客户洞察和数字化产品能力

    快速设计、交付及演进优质产品和卓越体验

    合作伙伴

    利用我们可靠的合作商网络来扩大我们为客户提供的成果

概况
  • 汽车企业
  • 清洁技术,能源与公用事业
  • 金融和保险企业
  • 医疗企业
  • 媒体和出版业
  • 非盈利性组织
  • 公共服务机构
  • 零售业和电商
  • 旅游业和运输业
概况

特色

  • 技术

    深入探索企业技术与卓越工程管理

  • 商业

    及时了解数字领导者的最新业务和行业见解

  • 文化

    分享职业发展心得,以及我们对社会公正和包容性的见解

数字出版物和工具

  • 技术雷达

    对前沿技术提供意见和指引

  • 视野

    服务数字读者的出版物

  • 数字化流畅度模型

    可以将应对不确定性所需的数字能力进行优先级划分的模型

  • 解码器

    业务主管的A-Z技术指南

所有洞见

  • 文章

    助力商业的专业洞见

  • 博客

    ThoughtWorks 全球员工的洞见及观点

  • 书籍

    浏览更多我们的书籍

  • 播客

    分析商业和技术最新趋势的精彩对话

概况
  • 申请流程

    面试准备

  • 毕业生和变换职业者

    正确开启技术生涯

  • 搜索工作

    在您所在的区域寻找正在招聘的岗位

  • 保持联系

    订阅我们的月度新闻简报

概况
  • 会议与活动
  • 多元与包容
  • 新闻
  • 开源
  • 领导层
  • 社会影响力
  • Español
  • Português
  • Deutsch
  • English
ThoughtWorks菜单
  • 关闭   ✕
  • 产品及服务
  • 合作伙伴
  • 洞见
  • 加入我们
  • 关于我们
  • 联系我们
  • 返回
  • 关闭   ✕
  • 概况
  • 工匠精神和科技思维

    采用现代的软件开发方法,更快地交付价值

  • 客户洞察和数字化产品能力

    快速设计、交付及演进优质产品和卓越体验

  • 低摩擦的运营模式

    提升组织的变革响应力

  • 智能驱动的决策机制

    利用数据资产解锁新价值来源

  • 合作伙伴

    利用我们可靠的合作商网络来扩大我们为客户提供的成果

  • 企业级平台战略

    创建与经营战略发展同步的灵活的技术平台

  • 返回
  • 关闭   ✕
  • 概况
  • 汽车企业
  • 清洁技术,能源与公用事业
  • 金融和保险企业
  • 医疗企业
  • 媒体和出版业
  • 非盈利性组织
  • 公共服务机构
  • 零售业和电商
  • 旅游业和运输业
  • 返回
  • 关闭   ✕
  • 概况
  • 特色

  • 技术

    深入探索企业技术与卓越工程管理

  • 商业

    及时了解数字领导者的最新业务和行业见解

  • 文化

    分享职业发展心得,以及我们对社会公正和包容性的见解

  • 数字出版物和工具

  • 技术雷达

    对前沿技术提供意见和指引

  • 视野

    服务数字读者的出版物

  • 数字化流畅度模型

    可以将应对不确定性所需的数字能力进行优先级划分的模型

  • 解码器

    业务主管的A-Z技术指南

  • 所有洞见

  • 文章

    助力商业的专业洞见

  • 博客

    ThoughtWorks 全球员工的洞见及观点

  • 书籍

    浏览更多我们的书籍

  • 播客

    分析商业和技术最新趋势的精彩对话

  • 返回
  • 关闭   ✕
  • 概况
  • 申请流程

    面试准备

  • 毕业生和变换职业者

    正确开启技术生涯

  • 搜索工作

    在您所在的区域寻找正在招聘的岗位

  • 保持联系

    订阅我们的月度新闻简报

  • 返回
  • 关闭   ✕
  • 概况
  • 会议与活动
  • 多元与包容
  • 新闻
  • 开源
  • 领导层
  • 社会影响力
博客
选择主题
查看所有话题关闭
技术 
敏捷项目管理 云 持续交付 数据科学与工程 捍卫网络自由 演进式架构 体验设计 物联网 语言、工具与框架 遗留资产现代化 Machine Learning & Artificial Intelligence 微服务 平台 安全 软件测试 技术策略 
商业 
金融服务 全球医疗 创新 零售行业 转型 
招聘 
职业心得 多元与融合 社会改变 
博客

话题

选择主题
  • 技术
    技术
  • 技术 概观
  • 敏捷项目管理
  • 云
  • 持续交付
  • 数据科学与工程
  • 捍卫网络自由
  • 演进式架构
  • 体验设计
  • 物联网
  • 语言、工具与框架
  • 遗留资产现代化
  • Machine Learning & Artificial Intelligence
  • 微服务
  • 平台
  • 安全
  • 软件测试
  • 技术策略
  • 商业
    商业
  • 商业 概观
  • 金融服务
  • 全球医疗
  • 创新
  • 零售行业
  • 转型
  • 招聘
    招聘
  • 招聘 概观
  • 职业心得
  • 多元与融合
  • 社会改变
敏捷项目管理Pune技术

My Tryst with Lean and Cross Functional Teams

Preeti Mishra Preeti Mishra

Published: Jan 4, 2015

Do you happen to encounter the following challenges in your agile delivery project?

  • Issues are uncovered in the development phase or even after due to lack of communication between teams, which leads to a lot of waste
  • The stories get blocked and the cycle time goes for a toss.
  • The team tries to pull in new functionality from the backlog. This might also get stuck in any of the middle lanes(In Dev or QA or ready for Release).
  • Thus time to release a piece of functionality increases significantly

I  experienced such issues on a project and we tried to solve them by using the following methods.It was a learning opportunity which ultimately resulted in a very successful and enriching experience. 

Kanban

We maintained a kanban board for stories in the software life cycle. We aimed to create small releasable stories. If the stories were too big, we split them into tasks. 

Swarming - The devs swarmed on the tasks of the story. Swarming means that everyone in the team works of the same story at the same time. As a result, stories moved through the Development column faster. This ensured that we had releasable functionality before picking new features.

WIP limits -  Each column in the swimlane had a Work In Progress (WIP) limit based on the number of people working on that stream. For instance the Quality Analysis (QA) lane had the WIP limit set to one as there was one QA on the project who could work on just one story at a time. If some column was full to capacity then the team shared the work and helped unblock those members. 

Third party blockers - We also had a lane for third party blockers. Our application was dependent on other systems. This meant that stories we were planning on playing got blocked in Ready or even during development. We put these stories on the 3rd party blocked lane to ensure increased visibility. This helped us follow up and resume work once we were unblocked. 

Expedite - The expedite column helped us work on priority feature requests or critical bugs. Each story takes some time to go through all the lanes before the story releases. Sometimes, a critical bug or feature request came through which took priority. Hence the bug/feature was critically analysed by the entire team before categorising it as a potential candidate for expedition. The team had to drop all other tasks and work on this story. At one time, only one story was allowed in that column. If all stories were expedited then the stories on the wall would be ignored for a long time.

User Feedback

It is important to seek user feedback as early as possible. In fact, by demonstrating  prototypes to users, the team was able to receive feedback before actual development started. If the feedback was positive we went ahead with the designs. If not, we knew what changes were required. This reduced wasted development time. The prototypes also gave the team a clear picture of the feature that we were supposed to deliver. 

The Four Amigos

In the A&D phase of the story, a developer, QA, Business Analyst (BA) and Experience Designer (XD) met to discuss the acceptance criteria (ACs) for the story. The BA would explain a happy path journey. The XD came up with the designs. The QA mentioned the ‘what if..’ scenarios and the expected outcomes were captured. The developer explained the implementation, what would be easier to include or exclude in the story and also gave inputs on how to split the story into tasks if needed. Only after this discussion, the story moved to the analysis and design done phase. This ensured that there was clear communication between all the parties involved. As a QA it helped me identify potential bugs before development. The developers ensured all the ACs worked as expected before passing the story to the QA. Ambiguities were resolved in this phase, saving the expense of making changes after development had finished. There is some investment, however, the benefits to the team were greater.

Cross functional teams

The four amigos flows into the concept of cross functional teams. A cross-functional team is a group of people with different functional expertise working toward a common goal. In this context, the developer, BA, QA and XD comprised the cross functional team.  The members pick up new knowledge and skills by participating in tasks (like the amigos session) that lie outside of their previous expertise. As well as keeping the team motivated, it helped the team to be more resilient against the temporary or permanent loss of certain team members. The team was able to function when a member was absent. For instance in the absence of a BA, the XD/QA/dev added the functional requirements to the story. In the absence of a QA the other developer pair or BA tested the story and moved forward. This is very helpful in teams where there is a single QA or BA. 

Multi team communications

Dependencies with other services proved to be a challenge initially. The project had geographically dispersed teams that we depended on. We stumbled into many blockers and had to wait for other teams came online and unblock us. This resulted in delays. To avoid this, the team aimed to resolve dependencies during analysis. We scheduled an online call during overlapping hours. This session, held at least weekly, helped build relations and understanding of what each team is working on. This enabled us to think consider possibilities of bugs in our system due to other team changes. We had contract tests written for each team, which flagged when changes would break things downstream or upstream.

All the processes that we introduced significantly improved our cycle time. The team had better collaboration , there were no surprises uncovered in development or after. We learnt a lot from each other and improved our own capabilities. 

  • 产品及服务
  • 合作伙伴
  • 洞见
  • 加入我们
  • 关于我们
  • 联系我们

WeChat

×
QR code to ThoughtWorks China WeChat subscription account

媒体与第三方机构垂询 | 政策声明 | Modern Slavery statement ThoughtWorks| 辅助功能 | © 2021 ThoughtWorks, Inc.