One of the biggest challenges facing the Scrum community is understanding the role of Product Owner(PO).
Most of the Scrum teams believe that PO is a mediator between the customer and the teams. That is, there is a strong belief that PO gathers requirements and passes it to the team. This way of working is the most ineffective way of doing software development. Any hand-off creates wastes and also, PO would end up becoming a bottleneck.
Instead, the most effective way would be for the PO to facilitate the conversation between customers and the teams as much as possible.The direct conversation is not only effective but reduces ambiguity,delay and avoids wastes.
Yes, I understand organizations say it is difficult to get customers on board and spend effort, time, money to engage teams. I guess this is where the organizations need to make a call, whether they want to build great products for the customers or the product owner !!
Great little post on Agile Otter: This is Not the End.Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
Replacing a 300 page design document with a product backlog filled with thousands of small user stories doesn't provide much benefit. Responding to uncertainty, emergence and change requires a plan which is flexible, communicates the game's vision and doesn't try to document uncertainty away.
Games need a product backlog with a couple of hundred stories at most. Upon hearing this, a question often asked is, "how do we encompass the scope of a large game in just a couple hundred stories?
The Level-of-Detail Metaphor
A useful metaphor to answer this question is the "Level-of-Detail" (LoD) technique, which are often used in video games. This technique chooses different copies of an object to render depending on how far the object is from the camera. In the example on the right, a distant boat will first use the low-polygon model on the bottom. As the boat approaches the camera, it switches to using the higher polygon (or triangle) models above. Ideally, as the boat approaches, you won't notice the models changing (old-popping).
The reason for using LoDs is that graphics engines and hardware have limits on the total number of polygons that can be rendered at 30 to 60 times a second. If you want to have hundreds of boats shown in your game, using LoDs is a common way to render them.
LoDs for User Stories
The same approach is used for the product backlog. The figure below shows some example LoDs for user stories:
Just as LoDs allow games to show a full, complex world on the screen, the LoD approach to product backlogs allows you to encompass the entire vision for the game in one view. Highly detailed documents or backlogs don't allow you to "see the forest through the trees" and, as with a forest, are easier to get lost in.
So you’ve decided to make the leap and build a hypermedia-rich API. Hopefully, this decision came from necessity and not boredom, but that’s a post for another day.
At this point, you’re presented with a bit of a problem. You have 3 main options for choosing/designing a media type:
- Pick a standard
- Design your own
- Extend a standard
As much as possible, I’d try to go with a standards-based approach. People with much more time on their hands and much more passion for you have thought about these problems for years, and probably have thought about more scenarios than you’re thinking of right now.
Instead of choosing media types in a vacuum, how would one compare the capabilities and intentions of one media type versus another? One way is simply to look at the design goals of a media type. Another is to objectively measure the level of hypermedia support and sophistication of a media type, with H Factor:
The H Factor of a media-type is a measurement of the level of hypermedia support and sophistication of a media-type. H Factor values can be used to compare and contrast media types in order to aid in selecting the proper media-type(s) for your implementation.
H-Factor looks at two types of support, links and control data, and different factors inside those.
For example, HTML supports:
- Embedding links
- Outbound links
- Templated queries (a FORM with GET)
- Non-idempotent updates (a FORM with POST)
- Control data for update requests
- Control data for interface methods (POST vs GET)
- Control data for links (link relations – rel attribute)
But doesn’t support:
- Control data for read requests – links can’t contain accept headers, for example
- Support for idempotent updates – you have to use XHR for PUT/DELETE
With the quantitative and qualitative aspects factored in with client needs, you’ll have what you need to pick a media type. Unless you’ve already decided that this is all way too complex and run back to POJSOs, which is still perfectly acceptable.Making the choice
There are a *ton* of popular, widely used, hypermedia-rich media types out there:
And probably a dozen others. At this point, just be warned, you’ll probably spend upwards of a week or so to decide which variant you like best based on your client’s needs. You also don’t need to decide a single media type – you can use collection+json for collections of things, and HAL for single entities if you like.
One other thing I found is no single media type had all the pieces I needed. In my real-world example, I chose collection+json because my client mainly displayed collections of things. Show a table, click an item, then display a single thing with a table of related things. It didn’t need PUT/DELETE support, or some of the other control data. I just needed control data for links and a way to distinguish queries versus forms.
But collection+json didn’t *quite* have all the things I needed, so I wound up extending it for my own purposes, which I’ll go into in the next post.
Post Footer automatically generated by Add Post Footer Plugin for wordpress.
Change is happening fast and furious in the business world. With so much pressure to keep up, it can be hard to take your foot off the gas pedal, even for a few days. Occasionally, though, it’s important to pull over and check the map to make sure you’re still on the right road.
If you’ll excuse the extended metaphor, we’d like to humbly offer RallyON!™ 2015 as a rest stop on your way to business agility.
Register today for the RallyON 2015 Agile conference — and get ready to drive at the new pace of change. Join us as we condense the industry’s most dynamic ideas, strategies, and practices into three days of learning, inspiration, and fun.
When: June 15–17, 2015
Where: JW Marriott Phoenix Desert Ridge Resort & Spa in Phoenix, Arizona
Don’t miss this chance to connect with experts and peers. It’s a rare opportunity to gather fresh insights that will remove your most challenging roadblocks and push your projects forward!
See how organizations like yours are achieving outstanding business results using Lean, Agile, and DevOps practices.
Learn how to create an unstoppable delivery engine, with coordinated teams using the coolest new collaboration tools.
Find out how to amplify the success of your Agile release planning and quarterly business steering to deliver value at scale.
There’s something for everyone, so bring your colleagues! In fact, when you register as a team, you can save up to 30% off the registration cost. See Pricing for more details.Who’s Coming to RallyON?
C-level executives who need business agility to stay ahead of rapid change — whether it’s competition, disruptive technologies, rising consumer demands, or changing regulations
VPs and managers in development and product management who need to improve planning and coordination across teams, so they can connect strategy with execution and ultimately deliver business value
Development team members who are tired of fighting fires and want to gain visibility into work, balance priorities, and respond effectively to the needs of the business
Check out the agenda and search by track (we’ve got seven) to find the sessions that interest you most.
Don’t wait any longer. Register your team today!
Doomsday Machine is lost, if you
*keep* it a *secret*!"
- Missing acceptance criteria?A definition of done applies to all product backlog items, but sometimes you need to define a set of important requirements that are unique for individual stories before they are worked on. These are considered “conditions of satisfaction” for the product owner, or acceptance criteria.
Example: As a player, I want to see a Message-of-the-Day (MOTD) from the developer so that I learn useful things about the game.
Some acceptance criteria for this story might be:
- The MOTD window may only take half the screen.
- It’s only shown the first time someone starts the game during a calendar day.
Types of acceptance criteria:
- Specific functionality known up front (above).
- Special, non-functional requirements (e.g. memory or CPU performance limits), for example “The game should have ten of these effects running with less than 2 milliseconds per frame cost on the target platform”.
- A set of expected behaviors for a subset of features, such as needing persistence in saved games or needing specific tests for online gameplay.
- Known areas that will be incomplete. For example, if you’re implementing a jump feature, but don’t have enough animation support (and have failed to get more), an acceptance criteria might say “some animation transitions will pop”.
- Have a clean pass/fail, testable state.
- Won’t dictate implementation details.
Acceptance criteria can be added to a story any time before, and during, sprint planning. Usually they’ll be added in release planning, grooming and sprint planning with greater detail added as the sprint work approaches. The product owner doesn’t have to be the one to identify them all, but should be present when they are captured. I prefer to have the team there as well asking questions and suggesting acceptance criteria along the way. One useful approach is to have a member of QA or a developer capture any acceptance criteria during discussions of the story, especially in sprint planning.
Acceptance testing will focus the team on the outcome as much as the means of getting there. It allows the business side to build trust with the team and to improve how they communicate their needs. When trust exists, the business is less likely to worry about the sprint and interfere.
Jon Terry, COO at LeanKit, shares the most recent product enhancements, discusses what’s currently in progress, and provides a look at what’s ahead in LeanKit. About This Webinar Topics discussed during this webinar include: Enhanced Lean reporting rollout UI and board template updates Project scheduling improvements Project system integrations Informational Links Enhanced Lean Metrics: More Speed and Insight LeanKit, Integrated […]
Humans typically crawl before we learn to walk, and walk before we learn to run. But sometimes what we call running is really more like a walk, and sometimes when we’re in a real hurry we’ve been known to skip a step.
How we learn to get started with Agile can take a lot of forms. Many people begin with baby steps: piloting a single team or experimenting with daily standups. Others are eager to get into a fast cadence right away and launch whole delivery groups — coordinated teams working on business strategy — all at once.
How we gauge our speed and progress varies, too.
- Some organizations outgrowing stickies on a whiteboard don’t know how to take the next step.
- Some go through the motions of Agile without noticing that their form is pain-inducing, or they’re moving so fast that they don’t have time to look around for competitors.
- Some become so focused on the work in the moment that they lose sight of the finish line altogether.
- Many who are “winning” at Agile forget to retrospect on their success or how to further improve.
Where are you in your Agile journey? Are you eager to take the next step, but don’t know where to start? Do you wonder how you stack up against others?
Now you can find out. Take five minutes to take our Agile Quiz. Get immediate answers, see how you compare to others who do what you do, and get recommendations for what to do next.
If you get a few minutes to talk to your executives about agile… you’ve got to be really crisp about what you are asking for and why.
Far too often people get that few minutes and totally fail to explain why agile is important and why their executives should care.
If you have an opportunity to speak to your leadership team about agile, here are the four things you need to be able to communicate.
1. Show deep understanding of the problems that your executives are trying to solve. Not the problem YOU want to solve, but the problems that THEY are trying to solve.
2. Explain specifically what about the current organization is contributing to these problems and how doing more of the same isn’t likely to lead to a different outcome.
3. Explain the specific changes you’d like to make in the organization. You have to be VERY specific. You can’t tell people to think differently. You have a shot at asking them to behave differently.
4. Make a specific ask for permission… to do a specific action… to prove that your approach to solving the problem could work. Let the executive know specifically what kind of support you need.
You need to be able to do this in about 10 minutes. Here is an example.
1. I deeply understand that we are struggling as an organization to make and meet commitments and get product to market in a timely manner. Our competition is moving faster and taking market share.
2. Our problem is that people are spread too thin across too many initiatives. People are unable to estimate accurately, and when they do, the constant context switching is slowing them down.
3. I’d like to try an experiment where we form a complete cross functional team. Help the team prepare a really clear backlog and we’ll help them produce a working tested increment every couple of weeks.
4. Could I get your support to form a team around our new product. We’d like to use a method called Scrum to manage the team’s work and in three months we’ll be able to get a prototype ready for market.
Obviously, this is an oversimplified example, but I think you get the idea.
Walking into the C-Suite and telling them they don’t get it… that they need to change… that they need to empower people…that they need to let folks self-organize… IMO, doesn’t really cut it.
Just a quick comment as we close… if you don’t understand your executives problems, you don’t have a clear point of view about what is specifically broken, you don’t have a clear plan for how to fix it, and you don’t know how to ask your executive to take action…
Agile delivery practices use metrics as a foundation to quantify the unpredictable nature of understanding what someone has in mind. Stories are a set of words that convey an idea and translate one person’s imagination into an imaginary format called software. Given that we can debate what the definition of “is” is, estimating when some body of work will be done and how far we are in that body of work approaches impossible. However, all Delivery Managers are asked to do exactly that. End of Sprint reports are used to convey to the rest of the business where we are on an imaginary journey and when we will get there.
The Release burn up helps to describe how well the teams are able to complete the work planned for this release. In this team we can see that although the team is tracking to complete the scope originally planned in the release. Scope was added to the plan either by better understanding or changes in definition and the team is not able to complete the growth in scope. Also in this chart we see that the Product Owner is not accepting the scope. This could increase the risk of an on time delivery.
The bug chart helps to give some understanding of the quality of the work. It is important to report all of the defects in the code base. Deciding what to do about the defects is a subject for another blog.
Finally we want to report something about what is happening with the scope. The scope chart below just gives a snapshot in time of how things are going and what areas need focus. The chart shows that the scope is actively being managed but investment decisions may be affected by the discovered scope in one or more features.
The most important part of any report is not the numbers gathered but the narrative that goes along with the numbers. The story of this release so far is that scope has been found or added that the team cannot achieve but they are tracking to make plan. The defects are being well managed and do not appear to cause alarm. Scope is being managed but higher-level decisions need to be made. The View Report feature is not anywhere close to the high level estimate and will impact the team’s ability to take on other work. The team needs help to prioritize whether they should continue with this feature or look for other solutions.
What story is your status report telling?
Failing to Plan is Planning to Fail: Succeed with Agile Planning Framework and Its Four Planning Objectives
In the first blog post of this series of six, I explained the need for Agile Planning Framework with its four planning levels.
In this second blog post, I explain four objectives at each planning level, and how to use the proposed Agile Planning Framework to implement and operationalize your customized agile planning playbook.
Agile Planning Framework: 4 planning levels x 4 planning objectives covering 16 practices.
Table 1 presents the recommended Agile Planning Framework, with four agile planning levels represented by its four columns, and four key objectives represented by its four rows. The wording of each objective is the same for all four levels, offering a unified treatment of each objective at all four levels, and also making the objectives easy to understand and manage. However, the implementation of each objective with specific practices depends on the level. For each of the four objectives, there are four practices corresponding to four levels of planning. Altogether there are 4 x 4 = 16 practices covering all four levels of planning and four objectives. These 16 practices are numbered as 1.1 through 1.4, 2.1 through 2.4, 3.1 through 3.4, and 4.4 through 4.4.
Table 1: Customizable Agile Planning Framework with 4 Levels,
4 Objectives and 16 Practices
Objective 1 – Choose and include appropriate method for planning in your Agile Planning Playbook: At each level of planning, Row 1 of Table 1 shows which specific planning method to choose from a set of choices, what specific things to pay attention to, and things to avoid as they cause waste.
Objective 2 – Obtain required inputs for planning and do necessary preparation ahead of the planning sessions: Agile planners must obtain the inputs required for planning and do the necessary planning preparation ahead of each planning session (meeting or workshop). Organizational old habits and inertia might mean multiple reminders and follow-up with at least some people, which some planners may find distasteful (pulling the teeth experience), and may be tempted to skip this diligence. Without required inputs needed for planning and preparatory steps completed, the planning work to be done during a planning session will not be effective. Row 2 of Table 1 lists the input information needed for planning at each level.
Objective 3 – Develop your agile plan: At each level of planning, several outputs must be produced to develop the Agile Plan at that level. Row 3 of Table 1 lists many of these key outputs of the agile plan at each level of planning. Note that the agile plan also needs to specify how workflow against the plan will be monitored.
Objective 4 – Re-plan as required, and improve the agile planning process and agile planning playbook on an on-going basis: An agile plan is not an end-all in itself. As an agile plan gets implemented at each level, lessons are learned through experience, and new inputs are received from the environment (market changes, competitive changes, and business condition changes), the plan itself will need revisions (agile re-planning). The nature and method of re-planning change with the planning level. The need for re-planning must be understood by the highest level of management – an area where agile champions and coaches may need to put some effort to overcome old mindsets.
Lessons learned from developing and executing agile plans at all levels, lessons discussed at reviews and retrospectives at all levels, and inputs received from the environment should become the basis for on-going improvements of the agile planning process and the agile planning playbook at your organization.
Relationship among Agile Planning Framework, Agile Planning Playbook, Agile Plans and their Implementations
Figure 3 shows this relationship along with an explanatory legend. I encourage agile champions to use the Agile Planning Framework presented in this blog series (Blog 1 and 2) to guide the development of your customized Agile Planning Playbook. Customization is done in the way you choose planning levels and planning objectives, and implement 16 practices of Table 1. Agile Planning Playbook is part of the more comprehensive Agile Lifecycle Playbook. Four planning level-specific playbooks are part of the Agile Planning Playbook. Each level of planning provides the context for the next lower level of planning. Implementation at each level provides feedback to the agile plan at that level, and based on the nature of the feedback the agile plan may be revised.
Moreover, implementation at each level provides a second order – what I call “derivative” – feedback to the Agile Planning Playbook; for example, if there is a systemic trend based on several days of daily feedback, it may alter the Agile Daily Planning and Daily Scrum Playbook. As an example, if a team finds it difficult to hold to the scheduled start and end time of their daily Scrum meetings based on daily feedback from several days of work, then the team tries to find the root cause, fixes it, and revises its own Agile Daily Planning and Daily Scrum Playbook.
If a team finds that the same problems have recurred few sprints later even after “fixing” them as a result of an earlier sprint retrospective, the sprint planners and agile champions must explore deeper over the feedback data from a series of sprint retrospectives (hence it is called derivative feedback), address the root cause, and revise their Agile Sprint Planning Playbook. Feedback from few samples in agile implementation is usually enough to drive a change in the agile plan at that level, but it requires sustained or systemic feedback over several samples (derivative feedback) to warrant a change in agile planning playbook at that level. Sometimes, a feedback at one level of agile implementation may be so strong that it could alter the agile plan at a higher level. An agile implementation or a plan or sometimes even a playbook may be altered due to inputs from the environment (market changes, competitive changes, technology issues, business changes). This is not shown in Figure 3 to avoid clutter and to stay focused on the relationship among Framework, Playbooks, Plans and Implementation effort.
Guidelines for customizing the Agile Planning Framework: For a client-specific project of a relatively modest duration (say, six months), you may be able to skip Level 1 planning (Product Vision and Strategy) and start with Level 2: Release Planning, consisting of two release cycles of three months each.
Teams that are new to agile development may start with Level 3: Sprint planning and Level 4: Daily Planning and Daily Scrums. As they gain experience of few sprints under their belt, they may then start doing Level 2: Release planning, and with further experience start with Level 1: Product Vision and Strategy planning.
For entrepreneurial start-ups with high degree of uncertainty about their real customers and their real problems, and about technical feasibility of their solution, staring with a two-year long vision and strategy exercise may not be very productive. A start-up may spend the first several months on Level 3 (Sprints) and Level 4 (Daily) planning and execution to validate their assumptions, demonstrate prototypes to potential customers, and make small changes in the (implicit) strategy or even “pivot” (significantly change) the strategy based on feedback from short sprints. Only when they have a good understanding about real customers and their real problems, and have some confidence in technical feasibility of their solution, they may advance to Level 2 (Release) and finally to Level 1 (Product Vision and Strategy) planning.
For a very large organization with many portfolios, programs and projects, you may have five levels of planning: Portfolio vision and strategy, Product vision and strategy, Release planning, Sprint planning, and Daily Planning and Daily Scrums. Alternatively, you may choose to have multiple Agile Planning Books targeted for different lines of businesses or product lines.
For well-jelled, highly experienced and stable teams that have demonstrated a stable velocity pattern (velocity changes within a narrow range across successive sprints), Planning Level 4 can be substantially simplified. Such teams should still conduct Daily Scrum meetings and may break stories into SMART tasks, but may track the effort for an entire story, and not at the task level.
You may add one or a small number of new objectives (beyond four objectives in Table 1) to your Agile Planning Framework, if required for your specific situation. Ability to add new planning levels and new objectives makes the Agile Planning Framework extensible. If you decide to add new levels or new objectives, I will be very interested in knowing the reasons (you may send me an email at Satish.Thatte@VersionOne.com). If you delete or modify or relax any of these four objectives, your agile plan will be incomplete or inadequate or of poorer quality compared to a plan developed by rigorously and diligently following all four objectives.
From Agile Planning Framework to your customizable agile planning playbook: Agile champions owning the agile planning playbook have many important responsibilities:
- Take the Agile Planning Framework from this blog series and customize it to create your agile planning playbook, instead of developing the playbook from scratch. This will save you substantial effort and result into a better and higher-quality playbook.
- Choose your own method for implementing each of 16 practices of Table 1. Furthermore, you should explore how to integrate your agile planning playbook with your Agile Lifecycle Management platform (see below) as that will make its actual use by agile champions, agile planners and agile team members much more likely and natural.
- After getting the buy-in and commitment for agile planning from your senior executives, educate agile planners and stakeholders in your organization on the agile planning playbook to be used in your company, and also get their inputs in developing your agile planning playbook.
- Make sure that your agile planning playbook is followed by agile planners at all four levels of agile planning, and even more importantly agile team members do their work driven by those plans.
- Improve the agile planning process and the playbook on an on-going basis.
The resulting agile planning playbook can be a brief document or a set of wiki pages. However, this solution will be disconnected from and will be poorly integrated with your ALM platform, and may not get used much as it is an “out-of-band” solution; and for that reason, it’s not my favorite. I strongly recommend that you implement and operationalize your agile planning playbook as an “in-band” solution that is well-integrated with your ALM platform.
If you are using or planning to use VersionOne as your ALM platform, I encourage you to implement your agile planning playbook using VersionOne Communities, Templates, Reporting and Customization capabilities, pilot your playbook with few agile projects, and then roll it out at a larger scale. If you have questions on how to implement and operationalize your customized agile planning playbook or to implement a more comprehensive agile lifecycle playbook covering the entire agile project lifecycle, please let us know at Services@VersionOne.com.
Though last but not the least, the agile planning playbook is necessary but not sufficient for agile success. Excellence in agile project execution is also essential, in addition to be good at agile planning. However excellence in execution will not be effective in delivering business results without proper agile planning.
The next five blogs of this blog series: In the next blog (Blog 2 of this series), I will explain four objectives at each planning level of the Agile Planning Framework. In the following four blogs (Blog 3 to 6), I will explain the implementation and customization details for four practices needed to realize the four objectives at each planning level.
- Blog 3: Plan and Succeed Strategically using Your Agile Product Vision and Strategy Planning Playbook
- Blog 4: Plan and Succeed in each Release using Your Agile Release Planning Playbook
- Blog 5: Plan and Succeed in each Sprint using Your Agile Sprint Planning Playbook
- Blog 6: Plan and Succeed every Day using Your Agile Daily Planning and Daily Scrum Playbook
In Blog 6, I will also present a complete example of an Agile Planning Playbook based on the Agile Planning Framework.
If you have questions on how to implement and operationalize your customized Agile Planning Playbook or to implement a more comprehensive Agile Lifecycle Playbook covering the entire agile project lifecycle, please let us know at Services@VersionOne.com.
Your feedback: I would love to hear from the readers of this blog either here or by e-mail (Satish.Thatte@VersionOne.com) or on Twitter (@smthatte).
Dr. Satish Thatte is Agile/Lean Coach & Product Consultant at VersionOne. He has over 30 years of industry experience, covering 15 years of software development and management at Texas Instruments, Bellcore and LG Electronics, 7 years as VP of Engineering at several companies practicing agile methods, and 6 years of agile coaching and consulting engagements for over 50 clients with impact at the executive level. He obtained his MS and PhD degrees in Electrical and Computer Engineering from the University of Illinois at Urbana-Champaign.
His expertise is in application of agile-lean methods and getting business results, agile transformation, and scaling up agile methods. He has been a speaker at a number of organizations and events: NYC Scrum, NY SPIN, NJ SPIN, Philly SPIN and AgilePalooza. He is a member of the Scrum Alliance, Agile Alliance, and a Senior member of the IEEE, and has served as Director of Modeling and Simulation at the Conscious Capitalism Institute. Learn more about Satish and his blogs at LinkedIn and blogs.
Not long ago, I wrote that COBOL is not a dead language and there are still billions lines of COBOL code in production today. At COBOL’s inception back in 1959, the goal was to provide something close to natural language so that even business analysts could read the code. As a side effect, the language is really, really verbose. Each time a ruby, python or scala developer complains about the verbosity of Java, C# or C++, he should have a look at a COBOL program to see how much worse it could be :). Moreover, since there is no concept of a local variable in COBOL, the ability to factorize common pieces of code in PARAGRAPHS or SECTIONS is limited. In the end, the temptation to duplicate logic is strong. When you combine those two flaws: verbosity and duplicated logic, guess what the consequence is: it’s pretty easy in COBOL to inject bugs in conditions.
Let’s take some examples we’ve found in production code:Inconsistencies between nesting and nested IF statements
In the following piece of code the condition of the second nested IF statement is always TRUE. Indeed, when starting evaluation of the nested condition, we already know that the value of ZS-LPWN-IDC-WTR-EMP is ‘X’ so by definition this is TRUE: ZS-LPWN-IDC-WTR-EMP NOT EQUAL 'N' AND 'O'. What was the intent of the developer here? Who knows?
And what about the next one? The second condition in this example is by definition always TRUE since the nesting ELSE block is executed if and only if KST-RETCODE is not equal to ’02′ and ’13′:
In the following piece of code and in the same condition we’re asking ZS-RPACCNT-NB-TRX to be both equal to 1 and 0. Obviously Quantum Theory is not relevant in COBOL, and a data item can’t have two values at the same time.
The next example is pretty similar, except that here it is “just” a sub part of the condition which is always TRUE: (ZS-BLTRS-KY-GRP NOT = 'IH' OR ZS-BLTRS-KY-GRP NOT = 'IN'). We can probably assume that this was not what the developer wanted to code.
ZS-RB-TCM-WD-PDN cannot be greater than 9 since it’s declared as a single-digit number:
With version 2.6 of the COBOL plugin, you can track all these kinds of bugs in your COBOL source code. So let’s start hunting them to make your COBOL application even more reliable!
Python: UnicodeEncodeError: ‘ascii’ codec can’t encode character u’\xfc’ in position 11: ordinal not in range(128)
I’ve been trying to write some Python code to extract the players and the team they represented in the Bayern Munich/Barcelona match into a CSV file and had much more difficulty than I expected.
I have some scraping code (which is beyond the scope of this article) which gives me a list of (player, team) pairs that I want to write to disk. The contents of the list is as follows:
$ python extract_players.py (u'Sergio Busquets', u'Barcelona') (u'Javier Mascherano', u'Barcelona') (u'Jordi Alba', u'Barcelona') (u'Bastian Schweinsteiger', u'FC Bayern M\xfcnchen') (u'Dani Alves', u'Barcelona')
I started with the following script:
with open("data/players.csv", "w") as file: writer = csv.writer(file, delimiter=",") writer.writerow(["player", "team"]) for player, team in players: print player, team, type(player), type(team) writer.writerow([player, team])
And if I run that I’ll see this error:
$ python extract_players.py ... Bastian Schweinsteiger FC Bayern München <type 'unicode'> <type 'unicode'> Traceback (most recent call last): File "extract_players.py", line 67, in <module> writer.writerow([player, team]) UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in position 11: ordinal not in range(128)
So it looks like the ‘ü’ in ‘FC Bayern München’ is causing us issues. Let’s try and encode the teams to avoid this:
with open("data/players.csv", "w") as file: writer = csv.writer(file, delimiter=",") writer.writerow(["player", "team"]) for player, team in players: print player, team, type(player), type(team) writer.writerow([player, team.encode("utf-8")])
$ python extract_players.py ... Thomas Müller FC Bayern München <type 'unicode'> <type 'unicode'> Traceback (most recent call last): File "extract_players.py", line 70, in <module> writer.writerow([player, team.encode("utf-8")]) UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in position 8: ordinal not in range(128)
Now we’ve got the same issue with the ‘ü’ in Müller so let’s encode the players too:
with open("data/players.csv", "w") as file: writer = csv.writer(file, delimiter=",") writer.writerow(["player", "team"]) for player, team in players: print player, team, type(player), type(team) writer.writerow([player.encode("utf-8"), team.encode("utf-8")])
$ python extract_players.py ... Gerard Piqué Barcelona <type 'str'> <type 'unicode'> Traceback (most recent call last): File "extract_players.py", line 70, in <module> writer.writerow([player.encode("utf-8"), team.encode("utf-8")]) UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 11: ordinal not in range(128)
Now we’ve got a problem with Gerard Piqué because that value has type string rather than unicode. Let’s fix that:
with open("data/players.csv", "w") as file: writer = csv.writer(file, delimiter=",") writer.writerow(["player", "team"]) for player, team in players: if isinstance(player, str): player = unicode(player, "utf-8") print player, team, type(player), type(team) writer.writerow([player.encode("utf-8"), team.encode("utf-8")])
Et voila! All the players are now successfully written to the file.
An alternative approach is to change the default encoding of the whole script to be ‘UTF-8′, like so:
# encoding=utf8 import sys reload(sys) sys.setdefaultencoding('utf8') with open("data/players.csv", "w") as file: writer = csv.writer(file, delimiter=",") writer.writerow(["player", "team"]) for player, team in players: print player, team, type(player), type(team) writer.writerow([player, team])
It took me a while to figure it out but finally the players are ready to go!
The impression that “our problems are different” is a common disease that afflicts management the world over. They are different, to be sure, but the principles that will help to improve the quality of product and service are universal in nature. —W. Edwards DemingWhy the Focus on Principles?
SAFe provides an integrated set of proven practices that enterprises rely on to improve their solution development capability. Implementation of these practices however, often requires tailoring to address the needs of a specific organization. Should an enterprise use eight, ten or twelve week PIs? Should they have a System Team at the program or at the value stream level? Should DevOps functions be supported via a hybrid ART team or fully incorporated in each Agile team? What if you can’t integrate every day, or even every iteration? Should the trains be organized around capabilities or subsystems?
As a framework, SAFe can only take things so far, after that it’s up to the judgment of those doing the implementation. But how can SAFe provide guidance with this kind of decision-making? Answer: By clearly articulating the underlying principles that make SAFe safe.
To that end, we’ve developed nine principles that summarize the key tenets of Agile, Lean process and product development, Systems thinking and product development flow, as applied in the context of building large systems and solutions. These are the fundamental tenets, the basic truths and economic underpinnings that drive the roles and practices that make SAFe effective. Of course, you can’t possibly capture this complexity in only nine principles, but that doesn’t mean you shouldn’t try. To that end, we offer the following.
These new principles can be accessed from the new Principles tab. Each is hyperlinked to a short article that describes the principle in further detail.The Sources
These principles incorporate lessons learned from applying Agile, Lean and SAFe practices in the field for over a decade, in a hundred different contexts. We’ve observed, recorded, drafted, revised, incorporated feedback and tried again. It’s from this field experience that we’ve observed patterns that are effective in enterprise after enterprise. Underlying these successful patterns are the principles that cause those patterns to be effective. In order to find them, you just have to dig a little further into the theory, abstract a bit, write them down, read them, and then listen to what they tell you.
They are also derived from the Agile body of knowledge—from the Agile Manifesto to the many books and methods, Scrum, XP, Kanban—and dozens of books by the Agile thought leaders we all know so well. And in order to scale, we take our inspiration from Lean Thinking, and writings on human potential and knowledge creation from seminal and ground breaking authors Deming, Drucker, Pink, Oosterwal, Ohno, Nonaka and Takeuchi, Ries, Kim, Reinertsen, Liker, Ward, Kennedy, and many more. Some of these books represent a lifetime of learning condensed into a few hundred pages.
We are standing on the shoulders of giants. Let’s make sure we apply all that we have learned.
“Hi, I had a question. Our Scrum Master is acting like a manager, running all the meetings and assigning work. This is what they did before Scrum. I thought Scrum meant the team did this stuff?” - A developer
The values of Scrum apply here.
Scrum! Scrum! Scrum! Scrum!
The sprint is the team’s commitment to a goal. True commitment to the game and continuous improvement requires a level of ownership, otherwise it’s an environment of compliance and people don’t engage as well with that.
The barrier to allowing ownership is fear. I often hear the micro-managing Scrum Master’s fear of what will happen if the team doesn’t follow their leadership. "They might fail!", they cry. There is often an underlying suspicion that others on the team are not competent because they'll make mistakes. The news is that competence doesn't mean you don't make mistakes!
Allowing teams to make mistakes and safely fail from time-to-time requires trust and courage. Trust requires respect. A lack of trust and respect is a cultural root of evil. When I see locked supply cabinets, dictated core hours or time-sheets, web filters, people referred to as “resources” etc. I know that the true adoption of Scrum will be a bit harder.
How can this be done?
Courage is requiredShifting from a mindset of individual compliance to team commitment requires courage all around. The Scrum Master and the team must summon the courage to take chances and fail every once in awhile. Emboldening the team to find this courage is more challenging than micromanaging via a task spreadsheet, but it’s also more fulfilling. It doesn’t happen overnight, but trust and respect can be grown.
Scrum Masters can start with some simple things:
- Silence yourself! Stop doing all the talking. Learn to allow awkward silences. The team will fill the silence with their own ideas and solutions.
- Ask questions, even when you know the answer. Teach them to catch fish rather than giving them fish to eat.
- Be courageous. Demonstrate respect and protect the team.
For example: if an artist is having problems getting code to work with a model, the entire sprint goal is threatened, but the team's focus on their shared goal should guide them to solve this problem on their own. There is no need to blame the artist for not solving their own problem. There is no need for someone wearing a manager’s hat to assign an engineer to fix the problem.
Does this mean managers/producers should be fired?
Don't expect leadership to
be overthrown, but leveragedAn underlying fear from managers or producers jumping into the Scrum Master role is that they should continue doing what they've been good at in the past or they'll be let go.
In the ten years that I have been training teams to use Scrum, I haven’t seen this happen. I’m not saying it never will, but most stories I hear reflect my own as a manager in a studio that adopted Scrum.
I found that as teams became more self-organizing, there was a growing part of my time that needed to be filled with other things. Eventually, about half my day was freed up by not micro-managing. This wasn’t bad because the work that teams took from me was never the work I enjoyed doing. So, I joined a team as their product owner and ended up enjoying the work far more as I was closer to the game and the people making it.
This might not be the path for every manager. Agile should lead a studio to ask what practices and roles are benefitting their games and the people making them and what parts are not. Again, this can threaten the status quo, which is why a lot of larger, established studios have a harder time adopting agile.
"Now I can make cool movies about
monkeys taking over the world!"The bottom line is that these values have to win out for you to have full success with agile.