Skip to main content

Home/ Agilesparks/ Group items tagged systems

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
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

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

Growth Facilitator role on an OpenAgile team | Agile Advice - Working With Agile Method... - 0 views

www.agileadvice.com/...growth-facilitator-role

agileblog agile

shared by Yuval Yeret on 07 Jun 09 - Cached
  • The responsibility of the Growth Facilitator is about more than simply prioritizing New Work goals and tasks. I see the role as contributing to the organizational culture, and helping to build the business in a sustainable way.
  • As Growth Facilitator, I am also responsible for guiding the team toward delivering greater value for our stakeholders. At Berteig Consulting, our stakeholders don’t just include the company’s owners. Our stakeholders include a wide range of groups, including customers, suppliers, employees, and our families, all without whose support nothing we do would be possible. Delivering value to our stakeholders requires that we keep them in mind when we commit to our tasks each week.
  • When I first started, I made goals that were broad, saying for example “to take care of our clients” or “to work at a sustainable pace.”
  • ...2 more annotations...
  • Berteig Consulting can update the Certified ScrumMaster course content so that all CSM course participants receive the best value in the market.” As soon as I made the direction clear, the team self-organized and generated tasks required to achieve each goal.
  • As the Process Facilitator goes about helping the team overcome obstacles, it can become clear that the team needs to address a systemic challenge during one of the upcoming Cycles. The Growth Facilitator then states the need as a Cycle goal in a S.M.A.R.T. format, allows the team time to give feedback, and prioritizes the goal in the New Work list. When the goal is brought to a future Cycle Commitment Meeting, the team breaks the goal into tasks and solves the systemic obstacle that the Process Facilitator identified.
  • Yuval Yeret on 07 Jun 09
     
    Who is the Agilesparks Growth Facilitator? Who's the Process Facilitator for that matter? Interesting reading. Important aspect of managing self-organizing teams in my oppinion
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

מועדים - 0 views

www.selayouniversity.co.il/...Dates.asp

development training embedded-agile-list

shared by Yuval Yeret on 08 Jul 14 - Cached
  • Design of Distrib. & Multi-Core Systems & SoftwareDuration: 2d; Start dates:21/02/2007; 04/
  • Embedded Linux BasicsDuration: 3d; Start dates:19/03/2007; 20/05/2007;
Yuval Yeret

LSSC12: The Improvement Journey - Yuval Yeret on Vimeo - 0 views

vimeo.com/43222643

kanban conference talk vimeo improvement journey yuvalyeret video Continuous Improvement improvement-list agile-change-management-list

shared by Yuval Yeret on 22 Mar 14 - No Cached
  • Yuval Yeret on 22 Mar 14
     
    "This presentation was given at the Lean Software and Systems Conference 2012 (LSSC12). Lean/Agile is not just about delivering early and often, it is even more importantly about continuously adapting the way we work towards an improved capability of delivery. Yet how many of us have worked in a continuously improving organization? How many of us have seen one in real life? It's hard to keep management interested in Improvement for very long, making Continuous Improvement a holy grail of sorts. As Lean/Kanban practitioners we believe the only sustainable way to improve is via evolutionary emerging change. But if we the organization is not interested in pursuing it, we have a big problem. Through some challenging situations from real client work we will see a few patterns that fail and a few patterns that show more promise for energizing improvement. We will also look at improvement pace and how to apply kanban approaches to make the improvement more sustainable. We will also explore some local cultural aspects that might affect the drive (or lack of) towards improvement, and how to deal with them, with some interesting insights about the Israeli culture…"
Yuval Yeret

A veteran teacher turned coach shadows 2 students for 2 days - a sobering lesson learne... - 0 views

grantwiggins.wordpress.com/...days-a-sobering-lesson-learned

training

shared by Yuval Yeret on 25 Oct 14 - No Cached
  • Yuval Yeret on 25 Oct 14
     
    relevant guidance for training we do at AgileSparks as well some of this we already try to do, some we should... and obviously sobering for all of us with kids in the education system
Yuval Yeret

http://studios.thoughtworks.com/2007/5/10/continuous-integration-in-the-enterprise-with... - 0 views

studios.thoughtworks.com/...-enterprise-with-cruisecontrol

continuous_integration

shared by Yuval Yeret on 19 Jan 17 - Cached
  • One of the developers had checked in some code that failed the regression tests. The application, on which the company had spent considerable time, money and effort, was now in an uncertain state. It wasn't behaving as expected. In the past, this type of bug usually wasn't discovered for months. Usually, it wasn't discovered until the System Integration Testing cycle got underway. For this project, that wasn't scheduled for another 6 months.
  • In the past, this bug would have lingered in the code for 6 months before anyone even realized it was a problem
  • . The light had gone off only 6 minutes after the code had been committed. Notice: not 6 months...but 6 minutes!
  • ...1 more annotation...
  • I told them I just saved them $12,535! They looked around to figure out how. The reason I was there was simple. Earlier that year, those same IT managers had performed a series of calculations to estimate how much it cost the department each time a bug made its way out of development, into SIT, into User Acceptance Testing, or all the way into production. For this IT shop, one bug into SIT cost them $12,605 (and you can imagine how much a bug into production would cost.)
yaelgr

Functional Subgrouping the core method of Systems-Centered Training - developed by Y. A... - 0 views

www.youtube.com/watch

facilitation youtube video

shared by yaelgr on 11 May 15 - No Cached
  • yaelgr on 11 May 15
     
    Short description of facilitation tool
Yuval Yeret

James Shore: The Art of Agile Development: Simple Design - 0 views

www.jamesshore.com/...simple_design.html

james shore art development

shared by Yuval Yeret on 13 Jan 15 - No Cached
  • Simple Design AudienceProgrammers Our design is easy to modify and maintain
  • Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. —Antoine de Saint-Exupéry Any intelligent fool can make things bigger, more complex and more violent. It takes a touch of genius and a lot of courage to move in the opposite direction. —Albert Einstein
  • When writing code, agile developers often stop to ask themselves, "What is the simplest thing that could possibly work?" They seem to be obssessed with simplicity. Rather than anticipating changes and providing extensibility hooks and plug-in points, they create a simple design that anticipates as little as possible, as cleanly as possible. Unintuitively, this results in designs that are ready for any change, anticipated or not.
  • ...10 more annotations...
  • I don't think XP and patterns are conflicting. It's how you use patterns. The XP guys have patterns in their toolbox, it's just that they refactor to the patterns once they need the flexibility
  • You Aren't Gonna Need It (YAGNI) This pithy XP saying sums up an important aspect of simple design: avoid speculative coding. Whenever you're tempted to add something to your design, ask yourself if it supports the stories and features you're currently delivering. If not, well... you aren't gonna need it. Your design could change. Your customers' minds could change.
  • We do this because excess code makes change difficult. Speculative design, added to make specific changes easy, often turns out to be wrong in some way, which actually makes changes more difficult. It's usually easier to add to a design than to fix a design that's wrong. The incorrect design has code that depends on it, sometimes locking bad decisions in place.
  • Once and Only Once
  • avoid duplication. "Once and only once" is the Extreme Programming phrase. The authors of The Pragmatic Programmer [Hunt & Thomas] use "don't repeat yourself," or the DRY principle.
  • Self-Documenting Code Simplicity is in the eye of the beholder. It doesn't matter much if you think the design is simple; if the rest of your team or future maintainers of your software find it too complicated, then it is.
  • What if we know we're going to need a feature? Shouldn't we put in a design hook for it? In XP, the plan can change every week. Unless you're implementing the feature that very week, don't put the hook in. The plan could change, leaving you stuck with unneeded code.
  • Results When you create simple designs, you avoid adding support for any features other than the ones you're working on in the current iteration. You finish work more quickly as a result. When you use simple design well, your design supports arbitrary changes easily. Although new features might require a lot of new code, changes to existing code are localized and straightforward.
  • Simple design requires continuous improvement through refactoring and incremental design and architecture. Without it, your design will fail to evolve with your requirements. Don't use simple design as an excuse for poor design. Simplicity requires careful thought. As the Einstein quote at the beginning of this section says, it's a lot easier to create complex designs than simple ones. Don't pretend "simple" means "fastest" or "easiest.
  • Until recently, the accepted best practice in design followed the advice Erich Gamma now disavows: "The key to maximizing reuse lies in anticipating new requirements and changes to existing requirements, and in designing your systems so they can evolve accordingly."
1 - 20 of 26 Next ›
Showing 20▼ items per page