Skip to main content

Home/ Agilesparks/ Group items tagged Management

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Yuval Yeret

Scrum Log Jeff Sutherland: The Managers Role in Scrum - 1 views

jeffsutherland.com/...managers-role-in-scrum.html

agileblog agile management managers

shared by Yuval Yeret on 01 Jun 09 - Cached
  • managers handle 'external stuff' to the team
  • ontract negotiations and procurement.
  • he role that a line manager plays in an employee's personal and professional development, often in the form of coaching or assisting in HR-related issues
  • ...11 more annotations...
  • - (1) Provides organizational vision- (2) Removes impediments- (3) Assists with individual development- (4) Challenges team beyond mediocrity while respecting team boundaries- Helps individuals without sucking the responsibility out of the team- Balances observer and contributor roles- Gives individuals tools to be a great team member- Coaches teams through conflict resolution- Advocates for continuous improvement for teams and the organization at large- Buys things for the team (manages budget)- Provides the right environment- Manages portfolio of projects
  • 1. Providing organizational vision: Often teams flail because there is no vision 'from on high'. Having this vision is important for team members to be able to relate their daily actions.
  • manager's role in this process to remove escalated impediments from the team(s).
  • provide strategic vision, business strategy, and resources
  • 3. Assists with individual development: We all have managers who mentor us in professional and sometimes personal growth. We felt that this is an important role for the manager to continue to play. Not all scrummasters have the authority or expertise to help in this regard.
  • a manager role would be like a 'ScrumMaster on steriods'- a person whose job it is to remove all escalated impediments for the team, take care of external stuff to the team, lead the team by challenging it, and assists direct reports with individual development and other HR-related challenges.
  • CMMI Level 5 Requirement 2.4.10 Review the activities, status, and results of the Agile Methods with higher level management and resolve issues (GP2.10)
  • ensure that higher level management has appropriate visibility into the project activities.
  • The principle of self-managed teams would say "let them be; let them find their own way." A principle of leadership, however, is to challenge teams. We discussed the fine line between challenging teams and taking away their ability to self-manage.
  • Jens Ostergaard
    • Yuval Yeret
      Yuval Yeret on 01 Jun 09
       
      my CST...
Yuval Yeret

Ideal Training for Enterprise-Scale Agility? « Scaling Software Agility - 0 views

scalingsoftwareagility.wordpress.com/...g-for-enterprise-scale-agility

shared by Yuval Yeret on 04 Jun 09 - Cached
  • training strategy for a significant enterprise that is contemplating an “all in” (immediate and across the entire company) enterprise scale transformation approach
  • for the enterprise, a combination of team-based and role-based training that would touch every practitioner is ideal
  • all team practitioners receive a minimum of two days of agile training, (agile team training for the each team in the enterprise)
  • ...11 more annotations...
  • an additional day or so of training for specialized roles of Product Owner, Project/Release Manager, and Agile/Scrum Master
  • All other executives and managers are invited to attend an overview course on scaling software agility
  • Agile for Teams –Essential, team-based training in a two day workshop
  • philosophy, principles, and benefits of agility, agile methods, iterative and release framework, roles, agile technical practices, and agile management practices (Scrum)
  • Agile Release and Project Management at Enterprise Scale – For Project Managers, Release Managers, Program and Portfolio Managers who have responsibility for helping deliver the product(s) to the marketplace. Topics include differences between traditional and agile product management, iteration framework, multi-level release planning and tracking, the agile release train, planning and executing the release planning event, and measuring enterprise progress.
  • Agile Product Owner in the Enterprise – For team-based product owners/candidates who will become responsible for backlog management, story writing, and iteration and release planning, and who will also be involved in the planning and coordination of larger scale software systems of systems built by teams of teams.
  • The Agile Master In The Enterprise – For potential agile team leads/future Scrum Masters who will be coaching agile teams and who will interact with other teams as well. Topics include: process facilitation, enterprise agility, mastering the iteration, team roles, release planning and tracking, agile leadership, empowerment and conflict management, and integration Scrums.
  • Agile Product Manager in the Enterprise – For enterprise product managers with product, product line, portfolio and business unit responsibilities. Topics include: what’s so different about agile, backlog and prioritization, relationship to product owners, PM’s role in release planning and management, visioning and the product roadmap.
  • Scaling Software Agility – Best Practices for Large Enterprises – For executives and key stakeholders in support, distribution, quality, internal IT, HR and all others whose roles will be impacted by the substantive changes that enterprise agile engenders. Part I – overview of agility highlighting lessons learned from the most common and effective agile methods Part II – seven team best practices of agility that natively scale to the enterprise level Part III – seven organizational capabilities that companies can master to achieve the full benefits of enterprise scale agility
  • The team member doesn’t need a CSM course, but he does need to know how to work in an agile environment.
  • what are the engineering practices need to support agile development? I’ve found that if developers only have their existing tools and practices, then they will continue to specify and develop waterfall-style within the sprints.
Yuval Yeret

InfoQ: Ensuring Success for Self Organizing Teams - 0 views

www.infoq.com/...lf-organization-success-factor

agile management self_org

shared by Yuval Yeret on 08 Jul 09 - Cached
  • Helicopter Managers – who step in too soon to rescue thereby depriving the team to think and solve problems together.
  • Absentee Managers – who would not step in at all irrespective of whether the team has all the necessary skills to tackle the problem.
  • If the team has sufficient skills to solve the problem then give them space else ask questions to help them get unstuck. This would help in building the skills eventually.
  • ...7 more annotations...
  • When time is not of the essence give the team time to work the issue. This would improve the team feeling and collaboration.
  • If the solution space is limited in scope and impact, or the decision is reversible, give the team space to solve the problem, even it there's a good chance they'll get it wrong the first time.
  • Tolerate mistakes and allow time for learning – management should not jump in at the first problem. They should allow the team to learn from their mistakes and take corrective action on their own.
  • Clearly define the boundaries – Without this the team is lost on how much they can manage themselves and when should they invoke management help. Without the definition of boundaries, teams err on side of caution and do not take any decision without seeking permission.
  • Keep the team challenged, yet not frustrated- The manager should be aware of the team’s skill level and limitations. He should be able to provide the team with enough challenges to keep them in a state of learning and growth.
  • emphasis on the balanced involvement of management with the team
  • It is important for the managers to be aware of the skill level of the team to step in or stay back at the right moment and act as a catalyst for the team to reach a state of self organization
Yuval Yeret

The Product Owner in the Agile Enterprise - 0 views

www.agilejournal.com/...-owner-in-the-agile-enterprise

agile product_owner embedded-agile-list

shared by Yuval Yeret on 07 May 09 - Cached
  • Responsibilities Vary by Software Business TypeSince the business mission, organization, operating methods, roles, titles and responsibilities differ dramatically across industry segments, it follows that the patterns of agile adoption vary across these segments as well
  • Information Systems/Information Technology (IS/IT) -teams of teams who develop software to operate the business; accounting, CRM, internal networks, sales force automation and the like. Customers are primarily internal to the enterprise.
  • Embedded Systems (embedded) - teams of teams who develop software that runs on computers embedded in other devices - cell phones, electronic braking systems, industrial controls and the like. Customers may be either internal or external to the enterprise.
  • ...17 more annotations...
  • Independent Software Vendors (ISV) -teams of teams who develop software for sale, including products like network management, supply chain management, mobile applications, etc. This segment now also includes the rapidly emerging Software as a Service (SaaS) vendors. Customers are external to the enterprise.
  • So far, former developers/tech leads with business sense and good project management skills seem to be the best fit.
  • ultimate user (mobile device user) is fairly far removed from the major technologies
  • Ryan went on to note that the title of "Program Manager" also performed a similar role in some larger scale contexts:
  • Embedded Systems Example - Symbian Software Limited
  • Clearly, the development of a mobile phone operating system is a highly technical endeavor
  • mention this because I suspect that the Technical Marketing Specialist role, where it exists in the ISV today, could make a good role model for the Agile Product Owner in today's larger ISV
  • the development process does not lend itself quite so easily to the traditional, customer/user facing, agile Product Manager/Product Owner roles. However, the Product Owner role must still be successfully addressed in this highly technical context.
  • All our POs come from engineering teams and are senior engineers with product or customer experience.
  • one PO to two team mapping typically, rarely 3 teams, sometimes 1
  • IS/IT Examples
  • role/title of the Business Systems Analyst
  • is often a reasonably good fit for the Product Owner role.
  • In the larger IT shop, I have also seen the role filled by Project Managers
  • In many cases, the self-managing and team-based planning lightens the workload for the project manager in the agile enterprise, and they often have the domain knowledge, inclination and insights necessary to fulfill the Product Owner role. Therefore, many have the time, skills and inclination to fill this role.
  • In our case, our product owners are in IT. They are the liaison to the business and in many cases speak for the business
  • Our Business Systems Analysts in IT are filling the role of Product Owner. Their previous responsibility of documenting detailed business requirements and rules now falls to the entire team in the form of user stories and acceptance tests
Yuval Yeret

Social, Agile, and Transformation: The ScrumMaster - A role or responsibility? - 0 views

ctotodevelopers.blogspot.com/...er-role-or-responsibility.html

agile scrum scrum_master

shared by Yuval Yeret on 24 Jun 09 - Cached
  • So if they needed the ScrumMaster role filled, then this was something they were prepared to train and assign to either a project manager or possibly a technical lead. The consensus of this team was, if you found a project manager skilled enough to have a real technical dialog with the development team, then this person could be trained and perform the ScrumMaster role.
  • The Scrum Alliance published a survey that has some supporting evidence. Over 60% of the 1100 people that responded to the survey had nine or more years of industry experience, 15% of them had twenty or more years of experience, and 35% had Masters degrees. Also, of the people who responded, 22% were project managers and another 21% were either Managers or Directors. So my simple translation is that practicing ScrumMasters are managers (project or other) with significant (10+) years of proven experience. Training and assigning this role to experienced project managers or software development managers seems like a viable approach to have the responsibility filled and having a dedicated ScrumMaster separate from these roles may not be necessary.
Yuval Yeret

Agile Game Development: The Project Manager Role - 0 views

www.agilegamedevelopment.com/...project-manager-role.html

agile manager

shared by Yuval Yeret on 01 Jun 09 - Cached
  • The Project Manager works with the Product Owner to insure that cost is always a consideration when evaluating the Product Backlog.
  • "Super Scrum Master"
  • Among the Project Manager's responsibilities:
    • Yuval Yeret
      Yuval Yeret on 01 Jun 09
       
      sounds like what some organizations will call "Program Manager"
  • ...6 more annotations...
  • Facilitate the Product Owner's role (backlog maintenance and meetings)
  • Tracking costs, especially for production
  • Tracking project risk
  • The Project Manager on a Scrum project has to be a Scrum expert and evangelist.
  • As each Scrum team on the project evolves their practices, the Project Manager will insure that they are continuing to work effectively with the other teams
  • One example of this would be the application of Test Driven Development and similar practices to build stability. It doesn't make sense for some teams to use TDD while others don't. The PM would have to step in and work with all the teams to insure that practices won't interfere or cancel each other out.
Yuval Yeret

How Google Sold Its Engineers on Management - 0 views

hbr.org/...ld-its-engineers-on-management

last-materials

shared by Yuval Yeret on 16 Mar 16 - No Cached
  • A good manager: 1. Is a good coach 2. Empowers the team and does not micromanage (See the sidebar “How Google Defines One Key Behavior”) 3. Expresses interest in and concern for team members’ success and personal well-being 4. Is productive and results-oriented 5. Is a good communicator—listens and shares information 6. Helps with career development 7. Has a clear vision and strategy for the team 8. Has key technical skills that help him or her advise the team
  • Employees with high-scoring bosses consistently reported greater satisfaction in multiple areas, including innovation, work-life balance, and career development
  • high-scoring managers saw less turnover on their teams than the others did—and retention was related more strongly to manager quality than to seniority, performance, tenure, or promotions
  • ...1 more annotation...
  • The key behaviors primarily describe leaders of small and medium-sized groups and teams and are especially relevant to first- and second-level managers. They involve developing and motivating direct reports, as well as communicating strategy and eliminating roadblocks—all vital activities that people tend to overlook in the press of their day-to-day responsibilities.
Yuval Yeret

Managing WIP isn't the same as Limiting WIP: Part 1 - 0 views

www.agilemanagement.net/...ManagingWIPisntthesameasL.html

kanban

shared by Yuval Yeret on 17 Jun 09 - Cached
  • To determine the truth of this we only need to look at the feature sets of the popular tools for managing eXtreme Programming and Scrum such as Rally, VersionOne, ScrumWorks, Mingle and very new tools like Borland Team Focus, to discover that not a single one of these tools allows you to set an explicit WIP limit. None of them provide a pull signal to start new work. Very few of them are even capable of reporting the quantity of work-in-progress.
  • s we learned more about the value of managing WIP, we introduced concepts to encourage and enable it, such as the use of Cumulative Flow Diagrams (a.k.a. Burn Up charts)
  • Agile teams encountering an impediment would generally mark a story as blocked and go on to another one
  • ...2 more annotations...
  • In a truly WIP limited process impediment removal is paramount.
  • So for those who would claim that Scrum and XP limit WIP and pull new work, such as Stephan Schmidt, I would point them to the feature sets of existing Agile tools. These tools do not impliment WIP limits, pull signalling nor are they particularly good at issue management and resolution. Recently, there are 4 new entrants to the Agile tools market. All of them producing WIP limiting Kanban tools including the same Mr. Schmidt. If earlier Agile methods had been truly WIP limited pull methods then tools from encumbent vendors would already reflect this. As a result there would be no market for new entrants such as CodeMonkeyism, AgileZen, LeanKit and RadTrack. More thoughts on managing WIP versus limiting WIP tomorrow... T
Yuval Yeret

Tailor your Message To Gain Support for your Agile Initiative | Enabling Agility - 0 views

www.enagility.com/r-your-message-to-gain-support

tailor agility agile adoption transformation

shared by Yuval Yeret on 21 May 09 - Cached
  • Connect Agile’s Benefits to your Company’s Priorities
  • aying that Agile is “better, faster, cheaper” may not be enough to cause a company to be willing to go through the often-painful process of cultural and process change.  You could implement Agile, but you could also try Six Sigma or Lean.  Saying that Agile is a general get-better remedy puts it in line with many other get-better methods.
  • f they don’t see a meaningful update from us, at least once a quarter, we’re going to get kicked out of the game.  We’ve all acknowledged that as we’ve gotten bigger, our processes have become more cumbersome and now is the time to do something about it.  Agile will give us the ability to regain that rapid pace of delivering innovations to market that we were know for in our early days.”
  • ...21 more annotations...
  • ur last two releases have looked like me-too updates, where we are just barely keeping up with our competitors
  • We’ve been losing market share
  • If you can refer to a specific business issue and show the linkage, you are much more likely to get a receptive audience.  Here’s an example.
  • The CFO, developer and QA manager have different roles in the organization and their needs are different.  If you want to enlist their support, be sure you know who you are talking to and what they value.
  • Use Focused Messages for Key Individuals or Groups
  • certain volume of people who are enrolled in the idea of Agile before you’ll see adoption start to accelerate,
  • People have specific needs in their role and they want to understand how Agile will affect and benefit them directly.  
  • Developers, on the other hand, probably wants to know if they will have interesting work, the opportunity to learn new things and the ability to make an impact on the company’s products.
  • a QA manager is probably interested in hearing how Agile helps enrich the QA profession.
  • The focus isn’t on Agile, its on business, as it should be.
  • The easiest way to find out what interests someone is to ask them.  When you meet, leave plenty of time for talk.  Motoring through a well-rehearsed Agile presentation usually doesn’t work.  A lot of times I’ll have slides with me, but they are a backdrop for the conversation.  I’ll refer to slides when it helps move the conversation along, but otherwise don’t use them.  You might want to forget slides altogether and just draw things on a whiteboard as necessary.  This technique is particularly useful with an individual or a small group.  
  • Take it One Step Further: Collect Data to Gain Insight
  • you’ll be most effective tailoring your message if you invest some time conducting data through a series of structured interviews. 
  • First, you’ll need a small set of questions prepared for the interviews.  Here are some examples. What is working with our current methodology? What’s not working with our current methodology? How do you think Agile would help our organization? What concerns do you have about Agile?
  • Interview a wide range of people: developers, testers, business analysts, managers, product managers, senior management, project managers and someone from finance. 
  • When you conduct the interviews, it is good to have one interviewer who has the primary responsibility for talking and the other person who has the primary job of taking notes.  You can switch off roles each interview so no one person gets stuck in either role.  Here’s how I typically start off.  
  • stories that people tell about the organization and make sure you write them down
  • I put all of the information we’d gathered into a mind-mapping program (Mindjet) and grouped like things together.
  • Make sure you keep interesting stories intact.  Specifics will help you make your cases
  • When there’s numerical data, people engage with a presentation in an entirely different way than they do when there are stories.  I find stories more effective, but do what works for you.
  • As an Agile evangelist, you job is to get Agile deployed effectively.  Along the way there are many people will be willing to go out of their way to help if you effectively speak to their interests and concerns.
Yuval Yeret

Larman's Laws of Organizational Behavior - Craig Larman - 0 views

www.craiglarman.com/...index.php

agile-change-management-list

shared by Yuval Yeret on 08 Jul 14 - No Cached
  • Yuval Yeret on 08 Jul 14
     
    "Larman's Laws of Organizational Behavior After decades of observation and organizational consulting, here are Larman's Laws of Organizational Behavior. These are observations rather than laws to follow ;) 1. Organizations are implicitly optimized to avoid changing the status quo middle- and first-level manager and "specialist" positions & power structures. 2. As a corollary to (1), any change initiative will be reduced to redefining or overloading the new terminology to mean basically the same as status quo. 3. As a corollary to (1), any change initiative will be derided as "purist", "theoretical", and "needing pragmatic customization for local concerns" -- which deflects from addressing weaknesses and manager/specialist status quo. 4. Culture follows structure. i.e., if you want to really change culture, you have to start with changing structure, because culture does not really change otherwise. and that's why deep systems of thought such as organizational learning are not very sticky or impactful by themselves, and why systems such as scrum (that have a strong focus on structural change at the start) tend to more quickly impact culture. i discovered that john seddon also observed this: "Attempting to change an organization's culture is a folly, it always fails. Peoples' behavior (the culture) is a product of the system; when you change the system peoples' behavior changes." "
Yuval Yeret

Challenging Why (not if) Scrum Fails | NetObjectives - 0 views

www.netobjectives.com/...questioning-why-scrum-fails

shared by Yuval Yeret on 22 May 09 - Cached
  • I do believe for Scrum to work beyond the team you need more than Scrum
  • what to add to Scrum making it more effective when it won't readily work
  • lack of team agility is not always the major impediment to Enterprise Agility
  • ...12 more annotations...
  • While starting at the team level with Scrum is often good, you often need to start with the product management team - that is, where product enhancements to be worked on are selected
  • Even when Scrum works at the team level, organizations very often report little impact to the bottom line.  While this is better than nothing (if the teams are happier, that's good), it usually doesn't justify a huge investment
  • in many contexts in which Scrum does not work readily, Scrum has no power to improve the context in which it is in.  In other words, the impediments that one must fix are often outside of the scope of what Scrum helps you do.
  • These impediments are often not even seen or if they are, are often viewed as "just the way it is."
  • certain Scrum attitudes often makes things worse
  • Scrum does little to let management to know how the team works or what impact management decisions have on the team
  • There is almost a religious zeal that Scrum tells you little of what to do
  • While SoS works well for certain types of work, it does not work well when the different teams have different motivations. 
  • the high failure rate is due to the fact that Scrum works in certain contexts but has little ability to change the contexts in which it doesn't work wel
  • One needs to pay attention to where to start as well as see how to change the context.  Separating the team from management doesn't help.  Focusing on only the team part of the value stream - giving little guidance both up and downstream of the team also doesn't help.  Lean provides guidance here (meaning Scrum with the aid of Lean could provide insights),
  • look into using Lean as a context for any improvement in your software development organization
  • While Scrum may be an appropriate choice in many circumstances, other methods may be better (e.g., Kanban Software Development).  Scrum's rapid ascension probably has more to do with its success in the places it easily fits.  Now that it is past the early adopter phase, we may see it having even a harder time as people attempt to scale it.
Yuval Yeret

"Lean Software Management: BBC Worldwide Case Study" - 0 views

leanandkanban.files.wordpress.com/...ldwide-case-study-feb-2011.pdf

kanban case study BBC article pdf davidjoyce petermiddleton metrics

shared by Yuval Yeret on 22 Mar 14 - No Cached
  • Yuval Yeret on 22 Mar 14
     
    "Lean Software Management: BBC Worldwide Case Study"
1 - 20 of 127 Next › Last »
Showing 20▼ items per page