I’ve been scraping the Game of Thrones wiki in preparation for a meetup at Women Who Code next week and while attempting to extract character allegiances I wanted to insert missing line breaks to separate different allegiances.
I initially tried creating a line break like this:
>>> from bs4 import BeautifulSoup >>> tag = BeautifulSoup("<br />", "html.parser") >>> tag <br/>
It looks like it should work but later on in my script I check the ‘name’ attribute to work out whether I’ve got a line break and it doesn’t return the value I expected it to:
>>> tag.name u'[document]'
My script assumes it’s going to return the string ‘br’ so I needed another way of creating the tag. The following does the trick:
>>> from bs4 import Tag >>> tag = Tag(name = "br") >>> tag <br></br>
>>> tag.name 'br'
That’s all for now, back to scraping for me!
Occam’s (or Ockham’s) razor is a principle we attribute to William of Ockham back in the 14th century. The principle states that “Entities should not be multiplied unnecessarily.” The popular interpretation is, the simplest explanation is usually the correct one.
It has inspired numerous expressions including “parsimony of postulates”, the “principle of simplicity”, the “KISS principle” (Keep It Simple, Stupid).
Most of Occam’s principles originate from philosophy. Maybe this is why you will now find many approaches (especially the principle of simplicity) in the basics of design principles.
Given a choice between functionally equivalent designs, the simplest one should be selected. Implicit in Ockham’s razor is the idea that unnecessary elements decrease a design’s efficiency, and increase the probability of unanticipated consequences. [¹]
When comparing technologies that perform the same function, one that is simpler in design will tend to be simpler to construct and repair. Additionally, it will tend to require greater skill to use, whereas a technology that requires less skill to use will tend to be more complex in design and more complex to construct and repair. For example, a straight razor is relatively simple in design and construction, but requires considerable skill to use, whereas an electric razor is relatively complex in design and construction but requires little skill to use. [²]Agile Frameworks
Now, go back and reread the two referenced passages, substituting design and technology with Agile framework. I also like the straight razor analogy, mostly because I shave using a straight razor. I only had to cut myself once (badly) before I realized I needed real skills to use such a simple tool. Counter to that, it took me several failures in complex organizations, to realize using a complex Agile framework does not translate to simple implementation.
Though I agree Scrum can address complex adaptive problems, I think it does so in a controlled team-level environment. I don’t see it working well on complex organizational-level environments. It’s like shaving a yak with a straight razor.
On the other end of the spectrum, we have SAFe, LeSS, DAD, [enter your acronym here]. These frameworks have emerged, in part I believe, because complex organizations expect complex solutions. We shave the yak, with an electric razor that Dr. Seuss would be proud of.My Thoughts
First, though larger organizations are often complex, we do not need to make Agile frameworks even more complex. It seems like very few customers care how they get work done. They just care that they deliver their product or service on time and within budget. If you’re looking to add control points to process and governance, look for what will lower risk and increase value throughput. Make processes as simple as possible and allow work to flow through your delivery system. Simplicity (by removing dependencies) is the key. Dependencies break Agile. While you should be careful not to add too many control points to a process, creating unnecessary work for everyone. Additionally, don’t simplify too much either, resulting in chaos. Focus on systematically removing dependencies and look for that happy medium. As a result, you may just need three things.
Just be careful not to cut yourself.
In an out-dated model of work environments, there are clear “rights” and clear “wrongs.” Usually, the management or leadership determines this and they call it “Policies and Procedures” or “Mandates” or simple “Rules.” There are usually severe consequences for not following these, intentionally or accidentally.
In the new and emerging agile model, where team members focus their attention on taking action with little planning, reflecting, learning and planning frequently work environments are very different.
Instead of looking for people to blame when challenges emerge, an agile team looks for ways to learn and develop. The team can collectively embrace new ways to adapt to change together.
This is one of the things I am learning about in high-functioning agile teams.
I like the way Brian Milner addresses this in his article “6 Ways to Bring Humility to your Agile Leadership Style.”Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
The post Article Review: Agile Teams Bend But They Don’t Break appeared first on Agile Advice.
Have you ever wondered why some people seem to be really good at getting results, while others struggle?
What are the true secrets of productivity that set one person apart from another, and help them achieve high performance?
I’ve studied the challenge of personal productivity deeply to really understand the difference that makes the difference.
I’ve put together a list of 25 Keys to Getting Better Results that cut to the chase and get to the bottom line of extreme productivity:
This list of productivity secrets is from my best-selling productivity book, Getting Results the Agile Way, and reflects the best of what I’ve learned in terms of what really makes some people stand out when it comes to personal productivity, high performance, and making things happen.
After all, who doesn’t want better results in work and life?
You can read the list of productivity secrets, but here I want to touch on a few key ideas.Vision
Vision is probably the single most important starting point when it comes to getting better results.
It’s hard to do anything if you don’t know what it’s supposed to be or do when it’s done.
If you can see the end-in-mind, then you are off to a good start.
And if you feel really good about the end-in-mind, then you have something to pull you forward versus trying to push yourself forward.
When your vision pulls you forward, you are on the right path.Value
Value is in the eye of the beholder and in the eye of the stakeholder.
Value is also the ultimate short-cut.
If you know what good looks like or if you know what’s actually valued, you can refocus your efforts on high-value activities that produce those outcomes.
When you don’t know who the value is for, or what good looks like, you are in trouble.
That’s why it’s important to check with the people you are producing value for, whether you are actually nailing their pains, needs, and desired outcomes.
If not, no problem – learn and adapt.
Learn early, learn often, and really get curious about which of your activities produce the highest value results.Velocity
Speed is the name of the game.
As John Wooden would often say, “Be quick, but don’t hurry.”
In other words, make your moves quickly, but with intention, and with quality.
Quality comes through practice and repetition. It’s how you learn.
Try things. But try then quickly, and experiment in how you product results.
Use speed as your friend to learn faster, and to build momentum.
Don’t get bogged down. Use speed to cut through your challenges, and quickly prioritize your best bets, and create a flow of continuous value.
Sometimes you will need to slow down to speed up.
But more often than not, you will need to speed up, so you that you are effectively taking massive action.
Few challenges withstand the onslaught of massive action, as long as you keep on learning and improving.
Well, that’s about it for now.
I hope that gives you at least a big of an edge that you can use in your day, every day, to get better, faster, simpler results for work and life.
When I think of POs and the team, I think of learning in several loops:
- The PO learns when the team finishes small features or creates a prototype so the PO can see what the team is thinking/delivering.
- The team learns more about its process and what the PO wants.
- If the Product Manager sees the demo, the Product Manager sees the progress against the roadmap and can integrate that learning into thinking about what the product needs now, and later.
Note that no one can learn if they can’t see progress against the backlog and roadmap.
There are two inter-related needs: Small stories so the team can deliver and seeing how those small stories fit into the big picture.
I don’t know how to separate these two needs in agile. If you can’t deliver something small, no one, the team, the PO, the customer, can’t learn from it. If you don’t deliver, you can’t change the big picture (or the small picture) of where the product is headed. If you can’t change, you find yourself not delivering the product you want when you want. It’s a mess.
When you don’t have small stories and you can’t deliver value frequently, you end up with interdependent features. These features don’t have to be interdependent. The interdependencies arise from the organization (who does what) and think they are talking about interdependencies in the features, but a root cause of those interdependencies are the fact that those features are not small and coherent. See my curlicue features post.
That means that the PO needs to learn about the features in depth. BAs can certainly help. Product Managers can help. And, the PO is with the team more often than the Product Manager. The PO needs to help the team realize when they have a structure that does not work for small features. Or, when the PO can’t know how to create feature sets out of a humungous feature. The team and the PO have to work together to get the most value from the team on a regular basis.
This is why I see the learning at several levels:
- The Product Manager works with the customers to understand what customers need when, and when to ignore customers. It is both true that the customer is always right and the customer does not know what she wants. (I won’t tell you how long it took me to get a smart phone. Now, I don’t know how I could live without one. You cannot depend on only customers to guide your product decisions.)
- The PO Value Team discusses the ranking/when the customers need which features. When I see great PO Value teams, they start discussing when to have which features from the feature sets.
- The PO (and BA) work with the team to learn what the team can do when so they can provide small stories. They also learn from the team when the team delivers finished work.
The larger the features the less feedback and the less learning.
So, I’ve written a lot here. Let me summarize.
Part 1 was about the “problem” of only addressing features, not the defects or technical debt. If you have a big picture, you can see the whole product as you want it, over time. For me, the PO “problem” is that the PO cannot be outside-facing and inward-working at the same time. It is not possible for one human to do so.
Part 2 was about how you can think about making smaller stories, so you have feature sets, not one humungous feature.
Part 3 was about ranking. If you think about value, you are on the right track. I particularly like value for learning. That might mean the team spikes, or delivers some quick wins, or several features across many feature sets (breadth-first, not depth-first). Or, it could mean you attack some technical debt or defects. What is most valuable for you now? (If you, as a PO have feature-itis, you are doing yourself and your team a disservice. Think about the entire customer experience.)
Part 4 talked about how you might want to organize a Product Owner value team. Only the PO works with the team on a backlog, and the PO does not have to do “everything” alone.
If you would like to learn how to be a practical, pragmatic Product Owner, please join me at the Practical Product Owner workshop, beginning Aug 23, 2016. You will learn by working on your roadmaps, stories, and your particular challenges. You will learn how to deliver what your customers value and need—all your customers, including your product development team.
- Sponsored: 64% off Code Black Drone with HD Camera
Our #1 Best-Selling Drone--Meet the Dark Night of the Sky!
As a trainer, (keynote) presenter, editor for InfoQ, and agile networker I go to conferences all around the world during the year. They are all different, each one has it’s own strong points. Now I’d like to hear from you: What’s your favorite agile conference? Please share your favorite agile conference by commenting on this post.
In 2016 I attended the Agile Practitioners Conference, Scaling Agile for the Enterprise, DevOps Summit, 1st Conference, QCon London, Agilia, AgileEE, Retrospective Facilitators Gathering, Software-Centric Systems Conference and GOTO Amsterdam. For these conferences I visited Tel Aviv, Brussels, Melbourne, London, Olomouc, Kiev, Sagres, Eindhoven and Amsterdam. Why go to conferences
Retrospectives Exercises Toolbox - Design your own valuable Retrospectives
People go to conferences for different reasons. I go to them to learn new things, stay up to date with what’s happening in agile communities and to share my experiences.
I really liked giving a keynote at the 1st conference because it was my first time to Australia which felt great. This conference had a fully packed program for people that are new to agile, I was amazed by it’s broadness in topics and the quality of the talks.
It was my second time to the AgileEE, and I felt at home right from the start. There’s always an lot of energy at this conference, people are networking everywhere and it’s the conference with a very diverse audience who’s eager to learn. The new venue was a real improvement.
The Retrospectives Facilitators Gathering is different because it’s a small group dedicated to agile retrospectives. It’s a full week open space on agile retrospectives, for me it’s the place to be to sharpen my facilitation and training skills. Upcoming conferences
In the coming months I will be attending the following conferences:
- Spark the Change London 2016
- SwanseaCon: Agile Development & Software Craftsmanship conference
- Agile Greece Summit 2016
- Workshop Getting More out of Agile and Lean at Goto Berlin 2016
- XP Days Benelux 2016
There are a couple more conferences coming up, which haven’t announced my workshops or talks yet. As soon as they become public they will be added to my conference schedule. Your favorite agile conference
So tell me: What’s your favorite agile conference? Please share your favorite agile conference by commenting on this post.
As a coach and committed Agile Evangelist, I spend most of my time convincing the software organization that they are actually part of the business. In this role, I also help with interpretations of Software / Technical jargon to business speak. Here are 5 of my favorite IT Director phrases:
- We are going to make the date at all cost.
- Refining requirements with business partners is bureaucratic and slow.
- It is up to the Operational team to clean up the process.
- We will work with DevOps to smooth out deployments.
- This new technology will speed up delivery once we re-write everything.
Now drumroll please, here is what they mean to the rest of the business.
- We are going to make the date at all cost. Actually means you need to have funding for 2 support people for every developer on staff. It will take one to three years to make this software run smoothly. At the end of the third year, we will make the case that it is too costly to maintain and try to make the date at all cost for a replacement.
- Refining requirements with business partners is bureaucratic and slow. Actually means we in IT can write a bunch of code much faster if we don’t have to understand how you are going to use it. We will just give it to you and you can figure out how to change your processes to make it work. If you can’t make it work, we can start up a replacement project.
- It is up to the Operational team to clean up the process. While delivering at all cost we created a bunch of manual steps, such as loading data directly to the production database. These manual steps will be turned over to technical operations with knowledge transfer sessions, i.e. someone sitting with someone but nothing actually written down. Once it is in the operational team, it is up to them to figure out how to automate these manual processes as long as they do not use development time.
- We will work with DevOps to smooth out deployments. We were busy delivering at all cost and never got around to automating our deployments. We are turning over that piece of work to the Delivery Operations team to automate. We don’t have time to document the deployment procedures but they have been working with us for the last few months so they can do it.
- This new technology will speed up delivery once we re-write everything. Actually means, I found something new and cool that I want to learn and it will look good on my resume. That old stuff is hard to maintain and change. We have no idea what most of that code is doing so let’s just start from scratch. We will not be able to make any business changes to the existing software. All of our efforts will be building the new software to do what the existing software already does.
Finally, the one that the IT Director says in the hallway but never in a meeting, “I have no idea what all these operational people are doing, I wish I could get that headcount for software delivery.”
Imagine if you could master your motivation, your productivity, and your time management?
It’s time to get your game on.
At Getting Results.com you can learn all about Agile Results. It’s more than just a time management system or a productivity system.
It’s a personal results system for work and life.
Agile Results is a simple system for meaningful results.
It helps you respond to change while making things happen. It helps you use your best energy for your best results, while you keep learning and improving.What Will You Find at Getting Results.com?
Getting Results.com is a source of insight, inspiration, and action for mastering productivity, motivation, time management and more.
Here are some of the key things you’ll have access to:
- Get Started with Agile Results.
- Articles on Agile Results, Goals, Motivation, and More.
- 7 Day Agile Results Jumpstart, helps you take Agile Results for a test-drive and potentially have one of your best weeks. Ever.
- 30 Days of Getting Results, this is advanced training that will help you get better results for work and life.
- Resources that include Cheat Sheets, Checklists, How Tos, Visuals, and more.
You can also read Success Stories to hear about how others have implemented and are using Agile Results.Getting Started with Agile Results
While there are a lot of resources at Getting Results.com, the most important thing you can actually do is just get started with Agile Results:
Take it for a test drive and see if you can create better results at work and in your life, the Agile Way.
The Trello board retrospective techniques for coaches, Scrum masters, and other facilitators provides exercises and ideas to design agile retrospectives. Philip Rogers created this board, he has added me so that I can contribute my experience with retrospectives.
This interesting retrospective resource on Trello has columns with:
- “All-in-one” plans for retrospectives, descriptions of exercises that cover the five phases mentioned below.
- Futurespectives, where the focus of the conversation is not on something that has occurred in the past, but instead on what the team foresees in its future.
- Activities for the five phases from the agile retrospectives book by Esther Derby and Diana Larsen.
Retrospectives Exercises Toolbox - Design your own valuable Retrospectives
The trello board with retrospective techniques has been added to the retrospective exercises toolbox.
I’ve contributed to the board by sharing my blog posts How Futurespectives Help Teams to Reach Their Goals, Retrospective Prime Directive in many languages and What to do when safety is low in a retrospective on this board. More will be added soon.
My mission is to help teams all around the world to increase the value of their agile retrospectives. There’s the book Getting Value out of Agile Retrospectives, the Retrospective Exercises Toolbox, workshops for Valuable Agile Retrospectives in Teams and for Increasing your Agility with Retrospectives and there are lots of blog posts on retrospectives. And you can Ask Your Agile Retrospective Question on line. All these things help you to make your retrospectives valuable.
A big thanks to Philip Rogers for providing me the possibility to share my experience and ideas for agile retrospectives on this board!
Recently, I discovered a well-written article on Scrum Alliance posted from a member entitled “Switching to the Agile Mindset.” In this article, the author lists six key components of the transformation individuals and teams go through as they adapt more agile mindsets and approaches to their work. I found this article ideal for new coaches and also useful for people on the team who may feel challenged by the switch.
The part which stands out for me the most is the phrase, “Change acceptance develops agility in a team.”
This concept is enshrined in the Agile Manifesto itself. Being able to adapt well to change is the cornerstone of the new mindset and a high-functioning agile team.Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
Getting thrown in to the deep end of any new responsibility can be quite a challenge – but none more so than the challenge of managing other people and their projects, when you have no experience with management!
As someone that has been through the ranks of project leadership and management, I’ve found a few principles to be consistent in learning how to delegate work to the people on my teams… a balance between two extremes that can be difficult to find.
So, what is the key to delegating work effectively – especially in your early days as a manager?
Find out in this episode of ThoughtsOnCode.Tweet
- Sponsored: 64% off Code Black Drone with HD Camera
Our #1 Best-Selling Drone--Meet the Dark Night of the Sky!
Some think they must act with “pretend certainty” for the benefit of their career. Others have convinced themselves of “arrogant certainty” where they believe they know the answer or solution but don’t (or can’t) provide any solid basis for this certainty. Unfortunately this arrogance can be interpreted as confidence that can be dangerous to the success of a company. Nassim Nicolas Taleb refers to “epistemic arrogance” that highlights the difference between what someone actually knows and how much he thinks he knows. The excess implies arrogance. What has allowed certainty within companies to thrive is that there is a distance between the upfront certainty and the time it takes to get to the final outcome. There lacks accountability between certainty at the beginning and the actual results at the end. Often times the difference is explained away by the incompetence of others who didn’t build or implement the solution correctly.
Of course, the truth is somewhere in between. The concept of certainty is actually dangerous to an enterprise since it removes the opportunity of acknowledging the options and allowing the enterprise to apply a discovery mindset approach toward real customer value via customer feedback loops and more.
We also want to avoid the inverse that is remaining in uncertainty due to analysis paralysis. A way to avoid this is to apply work in an incremental framework with customer feedback loops to enable more effective and timely decision-making. Customer feedback will provide us with the evidence for making better decisions. Applying an incremental mindset will enable us to make smaller bets that are easier to make and allow us to adapt sooner.
A healthier and more realistic approach is to have leaders who understand that uncertainty is actually a smart starting position and then apply processes that support gaining certainty. It is, therefore, incumbent upon us to have an approach that admits to limited information and uncertainty, and then applies a discovery process toward customer value. In the end, the beaten and battered Don Quixote forswears all the chivalric false certainty he followed so fervently. Is it time for management to give up the certainty mindset they think they have and instead replace it with a discovery mindset as a better path to customer success?
The post Making Unconscious Habits in Culture Conscious in Agile Teams appeared first on Agile Advice.
Just an update on the work we’ve been doing to speed up AutoMapper. I’ve captured times to map some common scenarios (1M mappings). Time is in seconds:Flattening Ctor Complex Deep Native 0.0148 0.0060 0.9615 0.2070 5.0 0.2203 0.1791 2.5272 1.4054 4.2.1 4.3989 1.5608 134.39 29.023 3.3.1 4.7785 1.3384 72.812 34.485 2.2.1 5.1175 1.7855 122.0081 35.863 18.104.22.168 6.7143 n/a 29.222 38.852
The complex mappings had the biggest variation, but across the board AutoMapper is *much* faster than previous versions. Sometimes 20x faster, 50x in others. It’s been a ton of work to get here, mainly from the change in having a single configuration step that let us build execution plans that exactly target your configuration. We now build up an expression tree for the mapping plan based on the configuration, instead of evaluating the same rules over and over again.
We *could* get marginally faster than this, but that would require us sacrificing diagnostic information or not handling nulls etc. Still, not too shabby, and in the same ballpark as the other mappers (faster than some, marginally slower than others) out there. With this release, I think we can officially stop labeling AutoMapper as “slow”
Look for the 5.0 release to drop with the release of .NET Core next week!